ChatGPT 把 8 亿用户押在它身上：为什么越来越多的项目正从 MySQL 搬进 PostgreSQL

先说结论

不是 MySQL 不好用了，而是时代的问题变了。十年前我们问的是「这个数据库快不快」，今天我们问的是「它能不能装向量、管 JSON、扛复杂报表，以及——它的老板明天还在不在」。前者 MySQL 依然是优等生，后者 PostgreSQL 几乎每题都赢。Stack Overflow 2025 年开发者调查里，PostgreSQL 以 55.6% 对 40.5% 碾压 MySQL；OpenAI 把 8 亿用户的 ChatGPT 跑在 PostgreSQL 上；而 MySQL 的开源仓库，曾经三个月没有一行新提交。这篇文章讲清楚三件事：这场「搬家潮」到底有多大、PostgreSQL 赢在哪、以及——冷静一点——什么时候你仍然应该选 MySQL。

图 1：本文封面（自制）。数据库江湖正在经历一场静悄悄的「搬家潮」。

一、问题背景：一场静悄悄的搬家潮

先回忆一下十年前。2015 年前后，你要做个网站、写个 App，数据库基本是闭眼选 MySQL：LAMP 组合（Linux + Apache + MySQL + PHP）就像当年的「结婚三大件」，WordPress、Discuz、无数电商系统都长在这上面。MySQL 是那个年代当之无愧的「默认选项」。

十年后的今天，风向彻底变了。最直观的证据是 Stack Overflow 2025 年开发者调查——这份每年有近 5 万名开发者参与的问卷，堪称程序员的「人口普查」：

图 2：真实截图。PostgreSQL 55.6%，MySQL 40.5%，差距拉大到 15 个百分点。要知道 2017 年 MySQL 还领先 PostgreSQL 将近 20 个百分点——八年时间，攻守完全易形。

有人说 Stack Overflow 调查只代表开发者口味，不代表生产环境。那再看 DB-Engines 排行榜——它综合搜索引擎热度、招聘需求、技术问答等维度，更像数据库界的「福布斯富豪榜」，2026 年 8 月的最新一期长这样：

图 3：真实截图。Oracle 第一、MySQL 第二、SQL Server 第三、PostgreSQL 第四。表面波澜不惊，但看分数变化就是另一个故事了：MySQL 一年蒸发了 97 分，而 PostgreSQL 与第三名 SQL Server 的差距已不足 10 分。

把镜头拉长到十年，趋势曲线更加一目了然：

图 4：真实截图。蓝绿色的 PostgreSQL 曲线是前十名里唯一一条稳定上扬的线，而 Oracle、MySQL、SQL Server 三座「大山」全在缓慢下滑。这就像班级成绩单：名次没变，但第一名的分数在跌，第四名的分数在涨，老师都知道接下来会发生什么。

更有说服力的是真金白银的下注。2025 年，Databricks 以约 10 亿美元收购了做 Serverless PostgreSQL 的 Neon，Snowflake 紧接着收购了 PostgreSQL 服务商 Crunchy Data。云厂商用钞票投票的方向，往往就是三年后架构师简历上的关键词。

二、问题表现：MySQL 这边，最近确实不太平

如果说 PostgreSQL 的上涨是「别人家的好消息」，那 MySQL 阵营 2025 年下半年以来的几件大事，就完全是自家院子里的动静了。

第一件事：核心团队被裁。2025 年 9 月，Oracle 对 MySQL 核心开发团队进行了大规模裁员，多位十年以上资历的老兵离开。MySQL 之父 Monty Widenius（后来出走创办了 MariaDB）公开表示「心碎」。有开发者统计发现，MySQL 开源仓库自 2025 年 9 月起一度超过三个月没有任何新提交，提交活跃度跌到项目历史最低点。

第二件事：社区公开信。2026 年 2 月，近 200 名开发者联名向 Oracle 发出公开信，要求它给 MySQL 一个明确的未来——要么好好投入，要么把治理权交给独立基金会。

图 5：真实截图（CODERCOPS）。一个数据库项目走到「用户给厂商写公开信」这一步，就像小区业主集体给物业递整改函——说明信任的裂缝已经不只是技术问题了。

第三件事：版本策略让人犯晕。MySQL 8.0 已于 2026 年 4 月结束支持（EOL），官方现在走「8.4 LTS + 9.x Innovation」双轨制。但很多团队升级时发现，9.x 系列一年跳了好几个大版本（从 9.0 一路到 9.7），一些旧功能被陆续移除，升级路径像一条「边修路边通车」的高速公路——能走，但颠簸。

公平地说，MySQL 并没有躺平：9.x 终于加上了原生 VECTOR 向量类型、JSON 二元性视图（JSON Duality Views）和 JavaScript 存储程序。问题是，这些功能 PostgreSQL 早就有了（pgvector 2021 年就发布了），MySQL 更像是在补一张别人五年前就交了的卷。

三、问题分析：PostgreSQL 到底赢在哪

好，现在进入技术环节。PostgreSQL 的领先不是一两个功能的差距，而是四个维度的系统性优势。我会尽量用生活里的比方讲清楚。

3.1 并发模型：涂改原件 vs 每人发一张复印

想象一本家庭相册，全家人都在看。现在要改其中一页的「余额」数字（从 100 改成 80），有两种改法：

MySQL（InnoDB）的做法是直接在原件上涂改：把旧数字划掉、写上新数字，被划掉的旧内容塞进一个叫 undo log 的「回收站」。涂改期间，想看这一页的人理论上可以看回收站里的旧版，但实现上有不少限制；而在一些老配置或特定隔离级别下，读者是要排队等的。

PostgreSQL 的做法是复印一张新的：原页不动，另写一页「新版：80 元」。正在看相册的人继续看旧版，丝毫察觉不到变化；新来的读者直接看新版。谁也不挡谁。

这就是 MVCC（多版本并发控制）的两种实现路线。用一句话总结：MySQL 是「一份原件 + 回收站」，PostgreSQL 是「所有版本都摆在桌上」。

图 6：自制图解。读多写多的系统——订单、账单、社交 Feed 流——最怕的就是读者和写者互相排队，这恰好是 PostgreSQL 的主场。

这个差异在实际业务里意味着：你的报表系统跑一个十分钟的统计分析，不会卡住正在下单的用户；半夜做批量对账，不用给白天的高峰期让路。

3.2 插件生态：一台主机，一墙乐高

这是 PostgreSQL 最「不讲武德」的优势。它从设计上就支持扩展（Extension），一句 CREATE EXTENSION 就能给数据库插上新能力，就像乐高主机上插积木：

• pgvector：让 PostgreSQL 直接存储和检索 AI 向量，做 RAG（检索增强生成）不用再单养一套向量数据库；
• PostGIS：地理信息系统的事实标准，做「附近的人」「配送范围围栏」信手拈来；
• TimescaleDB：时序数据扩展，监控指标、IoT 传感器数据直接入库；
• Citus：水平分片扩展，把单机变成分布式集群。

图 7：自制图解。AI 时代最贵的不是数据库本身，是「少搬一次家」——向量、地理、时序、分片，PostgreSQL 一个顶四个。

这件事在 AI 时代被无限放大了。2023 年以后，几乎每个新项目都要叠一个「AI 检索」的 buff。如果数据库是 MySQL，你大概率要再部署一套向量数据库，然后痛苦地维护两边数据的同步；如果数据库是 PostgreSQL，装上 pgvector，业务表和向量躺在同一个库里，一条 SQL 同时查「价格低于 100 元」和「和这段话语义最接近」。少一套系统，就少一份半夜被叫起来修故障的概率。

最有代表性的案例是 OpenAI。2026 年 1 月，OpenAI 工程团队公开了 ChatGPT 背后的数据库架构：8 亿用户、每秒数百万次查询，跑在一个单主节点的 PostgreSQL 上（Azure PostgreSQL Flexible Server），外加分布在多个区域的近 50 个只读副本，p99 延迟保持在两位数毫秒，可用性五个九。

图 8：真实截图（StorageNewsletter 转述 OpenAI 官方博客）。全世界最大的 AI 产品，没有分库分表、没有分布式数据库，就是一个 PostgreSQL 主库加一堆只读副本。「PostgreSQL 撑不住大流量」这个上古论调，可以正式进博物馆了。

3.3 SQL 能力与开发体验：轿车和全地形车

如果说 MySQL 是一辆好开的轿车，PostgreSQL 就是一辆带全套越野套件的全地形车。日常代步区别不大，一旦路况复杂，差距立现：

• JSONB：PostgreSQL 的 JSON 是二进制存储、可建索引、可局部更新的「一等公民」；MySQL 的 JSON 功能这些年也在进步，但索引和操作符的丰富度仍有差距。半结构化数据（埋点、配置、第三方回包）往 JSONB 里一扔，查询飞快。
• 窗口函数 + CTE + 递归查询：复杂报表 SQL，PostgreSQL 写得出来而且优化器跑得聪明；MySQL 8.0 之后才补上窗口函数，优化器对复杂查询的处理能力公认仍逊一筹。
• DDL 事务：这是运维人员的命根子。PostgreSQL 里改表结构可以包在事务里，改到一半出问题，回滚，世界清净；MySQL 的 DDL 大多不能回滚，改错一个字段类型，可能就是一次线上事故加半天数据修复。

打个比方：MySQL 的 SQL 像家用厨房，灶台、锅、菜刀，炒家常菜够用；PostgreSQL 的 SQL 像餐厅后厨，多了烤箱、低温慢煮机和一整套刀具——你可以不用，但要用的时候它都在。

3.4 性能也没落下：PostgreSQL 18 的异步 I/O

过去黑 PostgreSQL 的标准话术是「功能强但性能不如 MySQL」。这个说法在 2025 年 9 月之后基本失效了：PostgreSQL 18 正式引入异步 I/O（AIO）子系统，官方基准测试中部分存储读取场景性能提升最高 3 倍，同时还支持大版本升级时保留优化器统计信息（升级后不再需要漫长的「性能回温期」）。

图 9：真实截图（postgresql.org）。页头横幅还能看到 2026 年 8 月 13 日刚发布的 18.6 和 19 Beta 3——对照 MySQL 仓库三个月无提交的那段日子，两个项目的「心跳频率」完全是两个世界。

四、问题根因：不是技术赛跑，是治理结构

聊完技术，该聊聊更根本的东西了。技术差距是可以追平的——MySQL 9.x 不就加上向量类型了吗？那为什么风向还在加速偏向 PostgreSQL？

因为选数据库，本质上是在选「谁说了算」。打个比方：

MySQL 像一套「商业物业公司」管理的小区。房子（代码）名义上是开源的（GPL），但物业（Oracle）说了算：修不修电梯、什么时候修、物业费涨不涨，业主没有投票权。2025 年物业裁员、保安亭空了几个月，业主们才发现：原来这个小区的服务质量，完全取决于物业老板今年的财报心情。

PostgreSQL 则是一个「业委会自治」的小区。它采用的 PostgreSQL License 接近 MIT/BSD——谁都可以免费用、随便改、拿去商用，而且它不属于任何一家公司。核心开发由全球社区共同推进，云厂商可以卖它的托管服务（AWS RDS、Azure、阿里云都有），但没有谁拥有它，也就没有谁能「撤回」它或者把它关进付费墙。

图 10：自制图解。技术差距会追平，治理结构不会。架构师为一个技术栈下注五年，赌的其实是它的治理模式能活五年。

这就是根因：PostgreSQL 的崛起，一半是技术胜利，另一半是信任迁移。 当开发者对「单一厂商控制的开源项目」越来越警惕（这些年大家见过的许可证变更、收购雪藏实在太多了），一个治理中立、协议宽松、社区健康的项目，自然成为避险资金的流向。

五、冷静一下：什么时候你仍然应该选 MySQL

批评一件事物很容易，难的是知道它的边界在哪。我不会劝你把所有 MySQL 都砸了——那是另一种不专业。以下几种情况，MySQL 依然是正确甚至最优的选择：

图 11：自制决策图。选型不是站队，是算账。

第一，存量系统别乱动。 如果你的电商系统已经在 MySQL 上稳定跑了五年，分库分表、读写分离、监控告警全套成熟，那「换成 PostgreSQL」大概率是负收益。数据库迁移的风险成本极高，技术债不是这么还的。

第二，简单 CRUD + 极高并发读。 博客、资讯、商品列表这类「读占 95%、逻辑简单」的场景，MySQL 的架构足够轻、调优资料足够多，配合缓存打遍天下。WordPress 生态更是绑死在 MySQL 上，没必要逆生态而行。

第三，团队技能栈是最贵的性能优化。 一支闭着眼睛都会修 MySQL 主从延迟的团队，换到 PostgreSQL 的前半年大概率是战斗力下降期。数据库出故障的凌晨三点，熟练度比先进性值钱得多。

反过来，如果是全新项目，尤其是：要叠 AI 检索能力、有大量 JSON/地理/时序数据、SQL 报表逻辑复杂、或者团队没有历史包袱——2026 年的今天，PostgreSQL 就是那个「不会错的默认选项」。上限更高，退路更多，且没有房东。

六、Q&A

Q1：我现在学数据库，直接学 PostgreSQL 可以吗？ 可以，而且推荐。它 SQL 标准支持最完整，学会 PostgreSQL 再碰 MySQL 是「向下兼容」，反过来则要补课。招聘市场上 PostgreSQL 岗位的增长也明显更快。

Q2：MySQL 会不会死掉？ 不会。它的存量太大了——WordPress 撑着全球近半网站，无数政企系统、ERP 跑在 MySQL/MariaDB 上。它更可能的剧本是「慢慢变成遗产技术」：像 COBOL 一样，越来越少的新项目选它，但维护需求还会存在很多年。

Q3：PostgreSQL 有什么明显的缺点？ 有，诚实地说：连接模型较重（每连接一个进程，高并发下需要 PgBouncer 这类连接池兜底）；表膨胀（Table Bloat）需要关注 vacuum 健康；默认配置偏保守，生产环境必须调参；生态工具的中文资料密度仍不如 MySQL。另外它的大版本升级虽然逐年改善，但比 MySQL 8.0 时代的原地升级还是要麻烦一些。

Q4：国产数据库（OceanBase、TiDB、openGauss）和这个话题什么关系？ 关系很大——它们中的很多都选择兼容 PostgreSQL 或 MySQL 协议来「借力」生态。openGauss、IvorySQL 直接基于 PostgreSQL 演进；TiDB、OceanBase 主要兼容 MySQL 协议。换句话说，这两个生态的此消彼长，也在影响国产数据库的站队。

Q5：从 MySQL 迁到 PostgreSQL 难吗？ 中小规模（百 GB 级）不难，pgloader 这类工具可以搞定大部分场景；难的是大库的停机窗口控制、存储过程和触发器的改写（两边方言差异大）、以及运维体系的重建。建议先拿一个边缘业务试点，跑过一个完整的发布-回滚-扩容周期再谈核心库。

Q6：MariaDB 呢？它能接住 MySQL 的用户吗？ MariaDB 接住了「想要 GPL 纯血开源」的那部分用户，近年也在积极加向量检索等 AI 能力。但客观说，它的体量和生态与两大主线已拉开差距，DB-Engines 2026 年 8 月排在第 13 位。它是一个诚实的备胎，但不是下一个主角。

七、结尾

这场搬家潮的本质，可以用一句话收束：MySQL 赢得了一个时代，PostgreSQL 正在赢得下一个。

MySQL 的黄金时代，问题是「怎么扛住访问」；PostgreSQL 的黄金时代，问题是「怎么在一个数据库里装下整个 AI 应用」。没有对错，只有时代换了考题。

对架构师来说，真正值得记住的教训反而不是这两个名字，而是那条底层规律：选基础设施，先看治理结构，再看生态弹性，最后才看 benchmark 跑分。 因为跑分一年一变，而谁拥有这个项目的未来，决定五年后你要不要连夜搬家。

---

参考资料：Stack Overflow 2025 Developer Survey、DB-Engines Ranking、OpenAI: Scaling PostgreSQL to Power 800 Million ChatGPT Users、PostgreSQL 18 Released、MySQL’s Open Letter to Oracle、PostgreSQL vs MySQL 2026。