PostgreSQL 再vs MySQL
从功能层面讲,PostgreSQL 确实更强。支持数组、范围类型、JSONB 索引,扩展插件生态丰富,MVCC 实现更干净,标准 SQL 兼容性更好。腾讯、阿里、华为在做国产数据库的时候,底层技术都选了 PostgreSQL,而不是 MySQL,这不是偶然的。
Stack Overflow 2024 开发者调查也印证了这个趋势,PostgreSQL 已经以 48.7% 的使用率超过了 MySQL(40.3%),成为开发者中使用最广的关系数据库。

Stack Overflow 2024 开发者调查——数据库使用率排名(PostgreSQL 首次超过 MySQL 居首位)
你如果关注这个领域的话,估计也看到过类似的数据,在去年的最新统计中,PostgreSQL使用率已经到达55.6%,MySQL使用率稳定在40.5%附近。
另外有一个特殊点:数据库格局存在显著的区域差异,中国市场是一个重要的特例,国内 MySQL 的使用率仍高达 58.2%,而 PostgreSQL 为 27.6%,MySQL 保有绝对优势。
但这里有个很关键的信息:全球开发者调查中,在新项目里,开发者选 PG 和 MySQL 的比例大约是 3:1,PG 赢得很明显。但看全量的线上系统,MySQL 还是大头,市场占有率接近 40%,PG 只有 18% 左右。
这说明什么?说明有大量的系统建在 MySQL 上,而且没有换掉的动力。
这篇文章不是劝你用 MySQL,也不是劝你换 PG。我想聊的是:MySQL 凭什么还活着,而且活得挺好。
先快速铺垫一下 PG 强在哪
不展开讲,就说几个点,省得有人觉得我不了解 PG。
-
• 数据类型丰富:数组、JSONB、地理空间、范围类型,这些在 MySQL 里要么没有,要么实现很蹩脚。写过复杂查询的人应该懂,用原生 JSONB 和用 VARCHAR 存 JSON 字符串,是两个世界。
-
• 扩展插件生态:TimescaleDB 做时序,pgvector 做向量存储(现在做 AI 应用很多人直接选 PG + pgvector,连专门的向量数据库都省了),pg_trgm 做模糊搜索。MySQL 在这块基本没有对等的东西。
-
• 真正的开源授权:PostgreSQL 是 BSD-like 授权,完全自由。MySQL 背后是 Oracle,社区版和企业版之间有功能差距,这是事实。国内做信创的公司选 PG 也有这个考量在里面。
-
• MVCC 实现更彻底:PG 把多版本数据直接存在堆里,读写天然隔离;MySQL 的旧版本在 undo log 里,长事务容易让回滚段膨胀。
好,基本盘说完了。
那 MySQL 为什么没被淘汰
1. 人和工具链的惯性
这个东西很多人觉得是"历史包袱",带有贬义。其实我觉得应该换个角度看。
一家公司用了 MySQL 十年,DBA 都是 MySQL 出身,内部的备份脚本、监控告警、慢查询分析平台全是围绕 MySQL 搭的。这套东西换成 PG 不是不行,但要重新来一遍。不只是换个数据库,是整套运维体系要重建。
你要说这是"成本",确实是。但这个成本不是浪费,是已经沉淀的经验和工具。
市场上 MySQL DBA 的数量远超 PG。如果你今天要招人,MySQL 的候选人池是 PG 的好几倍。出问题了,Stack Overflow 上 MySQL 的答案更多、更完整。
说实话,在现有系统稳定跑着的情况下,换数据库这件事的收益你得想清楚,而不是看到 PG 功能更多就觉得应该换。
2. YouTube、GitHub、Slack 都在用 MySQL——Vitess 这条路
很多人觉得 MySQL 天然不适合超大规模。这个认知需要更新一下。
YouTube 后端核心数据库用的是 MySQL + Vitess。70000 多个节点,分布在 20 个数据中心,每秒处理几百万次请求,管的数据是 PB 级别的。Vitess 的角色是一个智能代理层,在应用和 MySQL 之间做透明分片,应用看到的是一个单一的 MySQL,实际背后是成百上千个分片。
GitHub 用 Vitess 管理 Issues 和 PR 的核心元数据,Slack 整个消息存储也是 Vitess。

Vitess 查询路由架构:VTGate 接收请求,通过 VTTablet 路由到各 MySQL 分片
PG 这边有 Citus,功能上没问题,但在这种"互联网级超大规模集群"的生产案例积累上,Vitess 目前还是更成熟。
所以如果你是做高并发读的互联网场景,MySQL + Vitess 这条路是有充分的大厂背书的。
3. 读密集型场景,MySQL 够用且轻
InnoDB 的缓冲池在处理大量简单读查询时很高效,多线程模型在高并发短连接场景下也比 PG 的多进程模型开销更低。PG 每个连接对应一个独立进程,连接数一高内存就涨;MySQL 是线程,相对轻量一些。
当然这个问题用连接池可以缓解,PgBouncer 就是干这个的。但如果你的应用没有连接池,直接打 DB 的话,MySQL 在这方面天然更从容。
对于一个 WordPress 博客或者读多写少的内容平台,MySQL 的表现已经很够用了。没有必要为了"功能更强大"去引入一个运维成本更高的系统。
4. 云上的 MySQL 已经不是原来那个 MySQL
很多人批 MySQL 的理由,比如主从复制延迟、备份慢、高可用麻烦,在云厂商做了深度改造之后,这些问题基本都解决了。
AWS Aurora MySQL 把存储层彻底重构,做了存算分离,只读节点可以秒级扩展,备份几乎是零影响。阿里云 PolarDB for MySQL 也是类似的架构。你用这些云产品的时候,其实用的是经过大规模改造的 MySQL,和原版 MySQL 不是一个东西。
这种情况下,很多企业觉得"MySQL 已经够好了",换 PG 的动力就更弱。毕竟云厂商帮你把短板补掉了。
5. 迁移过于麻烦
从 MySQL 迁到 PG,不是 mysqldump 导出再导入就完了。
SQL 方言有差异,AUTO_INCREMENT 在 PG 里是 SERIAL 或 IDENTITY,字符串拼接 MySQL 用 CONCAT(),PG 可以直接 ||,日期函数也不一样。ORM 层通常能帮你屏蔽一部分,但复杂的原生 SQL、存储过程、触发器都得人工翻译和验证。
然后还有数据类型映射、字符集、空值处理的细节差异,以及迁移期间要保证服务不中断的双写方案……
这个过程在一个中等规模的系统上做,花三个月是正常的,做一半发现坑再缩回来的也不少见。可能有小伙伴纳闷:就这?花三个月不行吗?你得考虑这三个月里需要多少人投入,期间其他需求全暂停,还有迁移风险带来的稳定性压力。
MySQL 自己也没有躺平
很重要的一点:MySQL 这几年其实也在追。
MySQL 9.x 系列加入了原生 VECTOR 数据类型,支持向量距离运算,矛头直接指向 PG + pgvector 的 AI 应用场景。Oracle 的 HeatWave 插件可以在不改应用的情况下加速 OLAP 查询,让 MySQL 在混合负载上也能打。
说实话,这些功能到目前为止还在追赶阶段,和 PG 的成熟度有差距。但至少说明 MySQL 没有停下来,而且背后有 Oracle 的资源在推。
但另一个动向是,WordPress 生态里 MariaDB 已经超过了 MySQL,原因之一是 MySQL 8.4 废弃了 SQL_CALC_FOUND_ROWS,这个函数是 WordPress 分页查询里用的,导致很多主机商转向了 MariaDB 作为默认选项。这也从侧面说明 MySQL 的版本升级并不总是那么顺畅,Oracle 的节奏和社区需求之间有时候会对不上。
怎么选
我自己碰到技术选型的时候,会问这几个问题:
团队里有没有 PG 经验?
如果没有,引入 PG 意味着学习成本和运维风险要同时承担。不是说不能学,是要评估值不值。
数据结构复杂不复杂?
业务里有大量嵌套 JSON 查询、数组操作、地理位置计算、复杂分析查询,PG 的优势才会真正体现出来。如果就是几张普通的 CRUD 表,两个数据库差别不大。
是新项目还是存量系统?
新项目,尤其是 SaaS 或者带 AI 特性的产品,我会优先考虑 PG,没有历史负担,直接用最好的。存量 MySQL 系统,除非有明确的痛点,我不会主动推动迁移。
是否在意开源协议的纯粹性?
做信创、做出海产品、对 Oracle 的控制有顾虑的,PG 的 BSD 授权是加分项。
有没有超大规模水平扩展的需求?
如果走 Vitess 这条路,MySQL 是更成熟的选择;如果走 Citus 或者自建分布式,PG 也可以。
最后说几句
说真的,我有时候觉得技术社区里"PostgreSQL 碾压 MySQL"这个论调有点过了。不是说 PG 不好,PG 确实强,但这种表达方式忽略了"场景"这个前提。
DB-Engines 的数据能说明一些问题:PostgreSQL 是现在唯一一个分数持续增长的主流关系数据库,MySQL 在下降,Oracle 也在下降。趋势上 PG 确实在赢。
但趋势是趋势,你现在手里的系统是你的系统。
MySQL 没有被淘汰,不是因为工程师们不知道 PG 更好,是因为每次技术切换都有真实的代价,而现有的 MySQL + 生态组合,在很多场景下依然是一个下限高、风险小、人才好找的选项。
如果你是在做新系统,2026 年这个时间点,我个人会优先选 PG。如果你是在维护一个 MySQL 系统,它稳定、没有明显瓶颈,可能真的不需要换。
一句话版本:PG 是更好的工程选择,MySQL 是更安全的组织选择。在很多公司里,后者的权重更高。
更多推荐

所有评论(0)