*—— 从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生态的分布式数据库 |
---
二、技术层面的"降维打击"
2.1 查询优化器：PG是专业的，MySQL是业余的
当业务跑到一定规模，老板开始要"日活留存"、"漏斗转化"这些复杂报表时，MySQL的弱点就暴露了：
MySQL的痛点：
- 复杂的JOIN查询慢成狗
- 子查询优化器偶尔还会"抽风"
- 窗口函数支持较弱
- 查询优化器被公认为开源界最强
- 支持极其复杂的JOIN算法（Hash Join、Merge Join）
- 拥有强大的窗口函数（Window Functions）
2.2 HTAP场景：混合事务/分析处理
| 场景 | MySQL | PostgreSQL |
|---|---|---|
| 简单读写 | ✅ 适合高并发 | ✅ 同样胜任 |
| 复杂报表 | ❌ 性能瓶颈 | ✅ 游刃有余 |
| 混合负载 | ❌ 容易跑挂 | ✅ HTAP原生支持 |
- 一边高并发写入
- 一边跑复杂统计报表
- 且不能把库跑挂
2.3 MVCC实现：架构设计的本质差异
两者的多版本并发控制（MVCC）机制完全不同：
| 维度 | PostgreSQL | MySQL (InnoDB) |
|---|---|---|
| 版本管理 | 每行存储多个版本，旧版本保留在堆中 | 只保留当前版本，旧版本在undo log中 |
| 读写隔离 | 读写完全隔离，支持可串行化快照隔离 | 长事务可能导致回滚段膨胀 |
| 并发表现 | 即使写数据，别人也可读取"之前的状态" | 未提交事务可能产生脏读 |
| 隔离级别 | 完整的可序列化隔离级别（SSI） | 幻读问题较难避免 |
2.4 数据类型的"降维打击"
PostgreSQL支持：
- JSONB：二进制JSON，支持索引和路径查询
- 数组：原生数组类型，支持多维数组
- 自定义类型：用户可以定义自己的数据类型
- 地理空间数据：PostGIS扩展
- 范围类型：时间范围、数值范围等
-- 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可能调整路线 | 由基金会主导，不受单一公司控制 |
- 用户驱动
- 技术优先
- 长期稳定
3.2 扩展生态：PG的"插件宇宙"
PostgreSQL拥有超过300个官方扩展，涵盖：
| 扩展 | 功能 |
|---|---|
| pg_trgm | 全文检索、模糊匹配 |
| TimescaleDB | 时序数据处理 |
| PostGIS | 地理信息系统 |
| Apache AGE | 图数据库 |
| Citus | 分布式数据库 |
| pg_stat_statements | SQL性能分析 |
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，就是选择了一个能陪你走得更远的技术伙伴。"*