PostgreSQL正在偷家MySQL：一场静悄悄的数据库范式转移

*—— 从LAMP时代到信创时代的技术选型变迁*

---

作为一名经历过LAMP时代的老架构师，我想聊聊这几年国内技术圈的一个有趣现象：

曾经一统江湖的MySQL，正在悄悄被PostgreSQL"偷家"。

这不是耸人听闻，而是一场静悄悄的技术范式转移。

---

一、现象：大厂们的集体"叛逃"

1.1 数据说话

根据DB-Engines最新排名：

PostgreSQL稳居全球第四
在开源关系型数据库中连续多年霸榜第一
更重要的是：它已经成为国产数据库创新的首选技术底座

1.2 国内头部企业的选择

厂商	产品	基于PostgreSQL的改造
腾讯云	TDSQL PG版（TBase）	引入GTM全局事务管理器，实现跨分片事务
阿里云	PolarDB for PostgreSQL	重构存储层，实现"一写多读共享存储"
华为云	GaussDB(for openGauss)	加入列存储引擎、AI优化器，支持HTAP
易景数通	openHalo	基于PG生态的分布式数据库

问题：为什么这些大厂不选择同样流行的MySQL，而是纷纷押注PostgreSQL？

---

二、技术层面的"降维打击"

2.1 查询优化器：PG是专业的，MySQL是业余的

当业务跑到一定规模，老板开始要"日活留存"、"漏斗转化"这些复杂报表时，MySQL的弱点就暴露了：

MySQL的痛点：

复杂的JOIN查询慢成狗
子查询优化器偶尔还会"抽风"
窗口函数支持较弱

PostgreSQL的优势：

查询优化器被公认为开源界最强
支持极其复杂的JOIN算法（Hash Join、Merge Join）
拥有强大的窗口函数（Window Functions）

数据对比： 在TPC-H标准测试中，当查询包含5个以上表连接时，PostgreSQL的执行计划生成时间较MySQL短41%。

2.2 HTAP场景：混合事务/分析处理

场景	MySQL	PostgreSQL
简单读写	✅ 适合高并发	✅ 同样胜任
复杂报表	❌ 性能瓶颈	✅ 游刃有余
混合负载	❌ 容易跑挂	✅ HTAP原生支持

PG的HTAP能力：

一边高并发写入
一边跑复杂统计报表
且不能把库跑挂

2.3 MVCC实现：架构设计的本质差异

两者的多版本并发控制（MVCC）机制完全不同：

维度	PostgreSQL	MySQL (InnoDB)
版本管理	每行存储多个版本，旧版本保留在堆中	只保留当前版本，旧版本在undo log中
读写隔离	读写完全隔离，支持可串行化快照隔离	长事务可能导致回滚段膨胀
并发表现	即使写数据，别人也可读取"之前的状态"	未提交事务可能产生脏读
隔离级别	完整的可序列化隔离级别（SSI）	幻读问题较难避免

测试数据： 在200并发事务场景下，PostgreSQL的冲突重试率较MySQL低37%。

2.4 数据类型的"降维打击"

PostgreSQL支持：

JSONB：二进制JSON，支持索引和路径查询
数组：原生数组类型，支持多维数组
自定义类型：用户可以定义自己的数据类型
地理空间数据：PostGIS扩展
范围类型：时间范围、数值范围等

性能对比： 在10万级数据量测试中，PostgreSQL的JSONB查询速度较MySQL快2.3倍。

-- PostgreSQL的JSONB路径查询，支持索引优化
CREATE INDEX idx_json ON api_data USING gin(data jsonb_path_ops);
SELECT * FROM api_data WHERE data @? '$.user.name ? (@ == "John")';

相比之下，MySQL 5.7+的JSON类型功能较弱，仅支持基础路径查询。

---

三、企业级特性的"代差"

3.1 开源协议的"致命差异"

这是很多企业容易忽视，但极其重要的一点：

维度	MySQL	PostgreSQL
许可证	GPL + 商业许可（Oracle控制）	BSD-like，完全自由
企业版vs社区版	企业版包含高级功能（审计、加密）	社区版即完整版，无功能阉割
源码透明度	Oracle掌控核心开发，社区贡献受限	全球开发者共同维护，开放透明
长期稳定性	Oracle可能调整路线	由基金会主导，不受单一公司控制

PostgreSQL是真正的开源：

用户驱动
技术优先
长期稳定

在当前复杂的国际技术环境下，BSD许可证允许自由使用、修改和分发，无需担心商业授权风险。

3.2 扩展生态：PG的"插件宇宙"

PostgreSQL拥有超过300个官方扩展，涵盖：

扩展	功能
pg_trgm	全文检索、模糊匹配
TimescaleDB	时序数据处理
PostGIS	地理信息系统
Apache AGE	图数据库
Citus	分布式数据库
pg_stat_statements	SQL性能分析

MySQL的扩展生态主要依赖存储过程和UDF，功能实现复杂度较高。

3.3 字符集与国际化支持

以字符编码与排序规则为例：

PostgreSQL：42种字符集编码 + 815种排序规则
MySQL：基本上只有5种字符集 + 几十个排序规则

这对企业级应用的多语言支持至关重要。

---

四、信创背景下的"政治正确"

近年来，随着信创推进与数据库自主可控需求提升，PostgreSQL的优势更加凸显：

4.1 技术底座价值

主流国产数据库均以PostgreSQL为基础：

国产数据库	基于PostgreSQL的改造
华为openGauss	深度优化，支持AI优化器
腾讯TDSQL	分布式事务增强
阿里PolarDB for PG	云原生架构改造
海量数据Vastbase	企业级安全增强
金仓KingbaseES	国产适配优化

4.2 BSD许可证优势

允许自由修改和分发
适合国产数据库厂商进行商业化改造
不受GPL传染条款限制

4.3 Oracle-free战略

摆脱对Oracle（MySQL母公司）的依赖
符合自主可控要求
避免潜在的地缘政治风险

---

五、理性选择：不做二极管

说了这么多PG的好，难道MySQL就要被扔进垃圾堆了吗？

当然不是！

作为一名理性的技术人，我们不做"二选一"的无脑站队，只选最对的场景：

选MySQL，如果：

✅ 业务是纯互联网高并发（社交动态、简单电商订单）
✅ 团队90%的人只懂MySQL，且不愿承担学习成本
✅ 严重依赖阿里云/腾讯云的深度定制版MySQL（如PolarDB）
✅ 需要简单的主从复制，不需要复杂功能

选PostgreSQL，如果：

✅ 数据结构复杂，包含大量JSON、数组或地理位置信息
✅ 需要做复杂的实时数据分析，但不想引入ClickHouse这种重型组件
✅ 对数据一致性要求极高（金融、科研、企业级ERP）
✅ 希望数据库能陪你走得更远，而不是业务稍微一复杂就得重构
✅ 需要复杂的事务处理和存储过程
✅ 需要强大的全文检索能力

---

六、趋势：不可逆的范式转移

6.1 DB-Engines趋势

从DB-Engines趋势来看：

PostgreSQL的发展势头非常迅猛
目前已经隐隐有追上MySQL的趋势
MySQL的受欢迎度一直呈现下降趋势

6.2 技术演进的必然

数据库选型正在从"够用就行"转向"面向未来"。

企业越来越意识到：

数据是核心资产
数据库是基础设施
选型错误会带来长期的技术债务

6.3 云厂商的推动

AWS、Azure、GCP等云厂商都在大力推广PostgreSQL：

Amazon RDS for PostgreSQL
Azure Database for PostgreSQL
Cloud SQL for PostgreSQL

云厂商的选择往往代表了技术趋势。

---

七、我的建议

初创期

可优先MySQL快速落地
团队熟悉度高，生态完善
专注业务验证，不过度设计

成长期

当数据复杂度指数级增长时
PostgreSQL的架构优势将更显著
考虑逐步迁移或新服务使用PG

信创/金融/政企

直接上PostgreSQL或其国产衍生版本
避免后期迁移成本
满足合规要求

---

八、结语：选择那头蓝色的大象

在这个数据驱动的时代，选择PostgreSQL不仅仅是选择了一个数据库，更是选择了一个更开放、更标准、更具扩展性的技术生态。

这或许就是为什么，当国内大厂们真正开始"玩真的"时，都不约而同地选择了那头蓝色的大象。

PostgreSQL的崛起不是偶然，而是技术演进的必然。

---

参考

DB-Engines排名: https://db-engines.com/en/ranking
PostgreSQL官方: https://www.postgresql.org/
腾讯云TDSQL: https://cloud.tencent.com/product/tdsql
阿里云PolarDB: https://www.aliyun.com/product/polardb
华为云GaussDB: https://www.huaweicloud.com/product/gaussdb.html

---

*"选择PostgreSQL，就是选择了一个能陪你走得更远的技术伙伴。"*