最近几年这个论调在公众号、知乎、B 站反复刷屏——
"PG 完爆 MySQL！" "JSONB 比 MySQL JSON 强一个数量级！" "MVCC 实现 PG 才叫纯粹！" "Oracle 把 MySQL 收了之后，PG 才是真开源！"
这些话单看都对 ——但翻一下国内主流电商 / 社交 / 短视频公司公开的技术分享、架构演讲、招聘 JD
，会得到一个一致的现象：MySQL 系仍然大量出现在核心 OLTP 链路 ——
- 阿里 / 京东 / 美团 / 字节 / 拼多多等公司对外公开的技术博客、QCon / ArchSummit 演讲、数据库岗 JD ——核心交易、订单、用户、商品 这条链路里，MySQL（含基于 MySQL 协议的自研 / 云上变体）出现频率远高于 PG ；
- PG / TiDB / ClickHouse 在这些公司里也都有—— 但更多出现在分析 / GIS / 时序 / 部分新业务 等差异化场景。
具体每家公司怎么决策、内部压测了什么、最后选型链路——外人看不到全貌、也别假装看到了 。但公开可证的现象 就是这一句话——核心 OLTP 这一档，MySQL 系仍然是国内的主流答案 。这不是偶然 ——下面就讲为什么。
说白了——选数据库这件事，从来不是"哪个技术上更强"——是"哪个工程下限更稳、修 bug 更快、招人更容易" 。这篇文章就把这条反主流的真相 讲清楚——不是为了贬低 PG（PG 真的很强），而是为了让你下次选型时别被对比表忽悠 。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
- 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
- 视频教程：https://doc.iocoder.cn/video/
不否认 PG 的强——但别堆 7 个、9 个、12 个优势——真正决定选不选 PG 的就 3 件 ：
PG 的 JSONB 是数据库领域真正没对手的特性 。它不是"能存 JSON"——MySQL 也能存——它是支持原生索引、原生查询、原生更新 ：
-- PG 给一段 JSONB 建 GIN 索引，查询走索引
CREATEINDEX idx_data ONeventsUSING GIN (data jsonb_path_ops);
-- 直接按 JSON 字段查询、走索引、毫秒级
SELECT * FROMeventsWHEREdata @> '{"user_id": 12345}';
-- 部分更新 JSON 字段
UPDATEeventsSETdata = jsonb_set(data, '{status}', '"done"') WHEREid = 1;
这套能力在 IoT、日志收集、事件审计、CDC 这种场景里——PG 一档独大 。MySQL 8.0 之后也补上了一些手段
——生成列（Generated Column）+ 函数索引 + 多值索引（multi-valued index） 能让 JSON 路径查询走索引，对中等规模够用 ；但生态成熟度、表达能力、原生 GIN 索引的开箱体验 ——和 PG 的 JSONB 仍然有量级差距。重度 JSON 业务（IoT / 日志 / 事件流）依然是 PG 主场 ——MySQL 适合"JSON 是配角、关系数据是主角"的场景。
PG 真正的杀手锏不是"功能多"——是功能可以无限扩展 。生态里这些都是大厂在跑的：
pgvector ——AI / RAG 的向量搜索——开源生态、索引能力、落地成熟度明显更强 （MySQL 9.x 也开始有 VECTOR 类型 + HeatWave Vector Store，方向上还在追赶 ）；PostGIS ——地理信息系统的事实标准——国内 GIS 项目 90% 跑在 PG 上 ；TimescaleDB ——时序数据库（自动分区 + 压缩）；pg_stat_statements ——SQL 监控的金标准。
PG 是「可编程数据库」 ——你能把整个系统当应用平台扩展；MySQL 更像一个「执行引擎」 ——只做 SQL 这一件事，做得很稳。
PG 在数据建模上给的工具更多 ——数组类型、范围类型、复合类型、自定义类型——直接把现实世界对象建模到表里 。MVCC 实现也比 MySQL 更"纯"——每行多版本、读写完全隔离、支持可串行化快照隔离。
但注意 ——这些优势在复杂建模 / 强一致性 / OLAP 这种场景里很值钱 ——电商商品 + 用户 + 订单这种 OLTP 业务库根本用不到 ——这是关键反差 。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
- 项目地址：https://github.com/YunaiV/yudao-cloud
- 视频教程：https://doc.iocoder.cn/video/
PG 那 3 条都是真的——但 MySQL 在国内市场份额没掉过一档。为什么？因为业务库的核心诉求不是"功能上限"——是"工程下限" ：
MySQL 装好默认配置就能跑——新人接手第一天能上手 。PG 装好之后还得手动调一堆参数 （shared_buffers / work_mem / max_wal_size / effective_cache_size）才能达到正常水平——对运维门槛要求实质高一档 。
国内大多数公司没有专职 DBA ——研发兼运维。MySQL 的"装上就能跑"在这种场景里省掉了一个人头 ——这不是技术问题，是组织成本问题 。
InnoDB 缓冲池 + 主从复制——读 QPS 上 10 万非常稳 。电商首页 / 商品列表 / 用户中心这类写少读多场景 ，MySQL 的工程化做得比 PG 更成熟 ——索引优化器经验丰富、内存管理调优文档齐全、压测案例满地都是。
PG 在 OLAP 场景吊打 MySQL——但国内业务大多数是 OLTP + 高并发读，正好是 MySQL 的主场 。
国内主流业务系统的技术栈——Spring Boot + MyBatis + Druid 连接池 + ShardingSphere ——这一套几乎全部以 MySQL 为一等公民 。换 PG 不是不行，但：
- ShardingSphere 对 PG 的支持远不如 MySQL 完整 ；
- ruoyi-vue-pro / yudao-cloud / 各种开源脚手架默认 MySQL ——换 PG 要改一堆 SQL 方言。
ruoyi-vue-pro 仓库：https://github.com/YunaiV/ruoyi-vue-pro
yudao-cloud 仓库：https://github.com/YunaiV/yudao-cloud
电商 / 内容 / 社交这种业务 70% 以上代码都是 CRUD ——MySQL 的现成生态直接节省研发时间。
阿里云 RDS / AWS RDS / 腾讯云 CDB——对 MySQL 的自动调优、备份、监控、读写分离、跨可用区高可用 都做到了极致——一键部署、一键扩容、一键还原——完全不需要 DBA 介入 。
PG 的云服务也在跟上——但国内云厂的 MySQL 文档 / 工具链 / SLA 比 PG 至少早 5 年 。这是历史窗口期带来的不可逾越优势 ——你做 618 大促压测，云厂的 MySQL DBA 团队随叫随到；PG 团队你得等。
这条最现实，也是最难量化的 ——你在国内招一个 MySQL DBA，简历投递量是 PG 的 5-10 倍 。CSDN / Stack Overflow / 知乎上 MySQL 的问题答案体系新人友好度极高 ——遇到问题 5 分钟搜出来；PG 有时候要跑去英文社区翻原文档。
对一个团队来说"招人快 + 出问题查得快" 直接决定能不能扛过 P0 事故 。这条不在技术对比表里，但在 CTO 心里排第一 。
把上面所有判断收敛到一张可以照抄的表 ：
底层判断标准 ：**"这个业务的核心挑战是高并发还是复杂建模？"** ——前者选 MySQL、后者选 PG。两者都要，可能你需要的不是 MySQL 也不是 PG——是 NewSQL（TiDB / OceanBase） 。
近年信创 + 数据库自主可控需求提升——PG 凭借开源彻底 + 功能强大成了国产数据库的首选技术底座 。国内多家头部公司基于 PG 深度定制：
- 腾讯云 TDSQL PG 版 （开源代号 TBase）——仓库 https://github.com/Tencent/TBase。引入 GTM 全局事务管理器 + 分布式协调，实现跨 shard 事务 ；
- 阿里云 PolarDB for PostgreSQL ——重构存储层，「一写多读共享存储」 ——秒级扩容只读节点；
- 华为云 GaussDB（for openGauss） ——部分兼容 PG 生态——官网 https://opengauss.org。加入列存储引擎、AI 优化器、支持 HTAP；
- 杭州易景数通 openHalo ——仓库 https://github.com/HaloTech-Co-Ltd/openHalo。
为什么集体押 PG，不押 MySQL ？两个原因：
- 协议彻底 ——PG 是 BSD-like，改了不用开源 ——商业化路径走得通；MySQL 的 GPL 协议商业化不友好；
- 功能上限高 ——大厂自研数据库要差异化竞争，PG 给的"复杂数据类型 + MVCC + 扩展机制"提供了足够的发挥空间 ——MySQL 的功能上限太低、没法做出技术差异。
注意——这是大厂做"产品"的视角 。对一线研发来说，业务库选型要考虑的是"工程下限"，不是"产品差异化" ——这是两个完全不同的视角，别混着看 。
PG 和 MySQL 不是谁更好——是谁更适合 ：
- 追求长期演进、复杂数据模型、强一致性的系统——
PG 是更坚实的基础 ；
- 快速上线、读多写少的 Web 应用——MySQL 仍然是高效之选 ；
- 亿级 OLTP / 多机分片——两个都不要选——直接上 NewSQL 。
回到开头那个问题——国内大厂业务库为什么还用 MySQL？
因为业务的真实诉求是「研发周期 + 故障响应 + 招人速度」 ——这些都是 MySQL 的强项；PG 的"功能上限"在 80% 的业务场景里根本用不到 。
国产数据库集体押 PG 是做产品的视角 ——他们要的是技术差异化；普通研发选业务库是做工程的视角 ——要的是工程下限。这两个视角混了，你就会得出错误结论 。
选数据库不是选最强的——是选 bug 落在哪里你能修得最快的那个 。
