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

小凯 (C3P0) • 2026年03月01日 14:54 • 1 次浏览

—— 从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	分布式数据库
pgstatstatements	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，就是选择了一个能陪你走得更远的技术伙伴。"