在大规模情况下，我认为MySQL仍然有竞争力，有几个原因：* 扩展惯性：是的，云供应商为Postgres提供了类似的分片和集群功能，但它们都相对较新。* 因此，招聘。找到大规模的MySQL专家更容易（尽管每年都在逐渐减少）。* 对于非常频繁的UPDATE操作工作负载，写入放大、索引膨胀和元组/页面膨胀。这就是现实。Postgres一直在不断改进，但它本质上是一个MVCC数据库。如果你的工作负载主要是UPDATE和简单的SELECT，Postgres最终会落后于MySQL。* 复制。Postgres的复制在过去5-10年里有了巨大的成熟，正如你指出的那样，云托管在某种程度上减少了对它的关注，但它在某些方面仍然与MySQL不同，这在大规模时可能会很烦人。最大的问题之一是进行混合OLAP+OLTP（比如，一个包含大量数据的数据库，以及面向用户的仪表板）。…
源讨论PlanetScale for Postgres现已正式发布原帖 190 条评论 · 导入时统计这个时候我不确定还有谁会去选择MySQL。它曾经拥有的任何优势在这些托管解决方案出现后基本上都消失了。 比如，MySQL更容易运行和连接。这些云服务（Planetscale、Supabase、Neon，甚至RDS）已经解决了这个问题。MySQL在读取密集型负载中更快。云供应商也已经解决了这个问题。
完整原文把你的经验，加入这段讨论。
> 混合 OLAP+OLTP ... 在 Postgres 中，这种模式需要仔细规划，以避免违反 max_standby_streaming_delay 等设置 在大规模情况下，这是一个非常棘手的问题，我很少看到其他人提到。你要么使用 max_standby_streaming_delay，这样与复制冲突的查询会导致复制延迟；要么使用 hot_standby_feedback，这样在 OLAP 备库上的长运行查询会在主库上造成问题。 在备库上使用逻辑解码也需要 hot_standby_feedback，这对于你的 ETL 备库来说是个巨大的麻烦。
完整原文我感谢你的详细回复，我同意你提到的所有观点。 不过我感到非常有趣的是，这个帖子中所有为MySQL辩护的人最后都会以某种形式的“我仍然会选择Postgres！”结尾。:)
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。