别再喊 PG 完爆 MySQL 了：阿里京东美团业务库都用 MySQL，不是他们没看 PG
👉这是一个或许对你有用的社群
🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：
《项目实战（视频）》：从书中学，往事中“练”
《互联网高频面试题》：面朝简历学习，春暖花开
《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题
《精进 Java 学习指南》：系统学习，互联网主流技术栈
《必读 Java 源码专栏》：知其然，知其所以然
👉这是一个或许对你有用的开源项目
国产Star破10w的开源项目，前端包括管理后台、微信小程序，后端支持单体、微服务架构
RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能：
多模块：https://gitee.com/zhijiantianya/ruoyi-vue-pro
微服务：https://gitee.com/zhijiantianya/yudao-cloud
视频教程：https://doc.iocoder.cn
【国内首批】支持 JDK17/21+SpringBoot3、JDK8/11+Spring Boot2双版本
先把现象摆桌面：阿里京东美团核心 OLTP 仍大量在 MySQL
PG 强在哪：3 个真正的杀手锏
MySQL 凭什么活到现在：5 个工程下限
一张选型决策表：你这个项目该选谁
国产数据库为什么集体押注 PG
说到底
先把现象摆桌面：阿里京东美团核心 OLTP 仍大量在 MySQL
最近几年这个论调在公众号、知乎、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 强在哪：3 个真正的杀手锏
不否认 PG 的强——但别堆 7 个、9 个、12 个优势——真正决定选不选 PG 的就 3 件：
杀手锏 1：JSONB——半结构化数据的 GOAT
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 是配角、关系数据是主角"的场景。
杀手锏 2：扩展机制——PG 是"可编程数据库"
PG 真正的杀手锏不是"功能多"——是功能可以无限扩展。生态里这些都是大厂在跑的：
pgvector——AI / RAG 的向量搜索——开源生态、索引能力、落地成熟度明显更强（MySQL 9.x 也开始有VECTOR类型 + HeatWave Vector Store，方向上还在追赶）；PostGIS——地理信息系统的事实标准——国内 GIS 项目 90% 跑在 PG 上；TimescaleDB——时序数据库（自动分区 + 压缩）；Citus——把 PG 变成分布式数据库；pg_stat_statements——SQL 监控的金标准。
PG 是「可编程数据库」——你能把整个系统当应用平台扩展；MySQL 更像一个「执行引擎」——只做 SQL 这一件事，做得很稳。
杀手锏 3：数据类型 + MVCC 实现更"学院派"
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/
MySQL 凭什么活到现在：5 个工程下限
PG 那 3 条都是真的——但 MySQL 在国内市场份额没掉过一档。为什么？因为业务库的核心诉求不是"功能上限"——是"工程下限"：
工程下限 1：极简部署——研发兼运维也能跑
MySQL 装好默认配置就能跑——新人接手第一天能上手。PG 装好之后还得手动调一堆参数（shared_buffers/work_mem/max_wal_size/effective_cache_size）才能达到正常水平——对运维门槛要求实质高一档。
国内大多数公司没有专职 DBA——研发兼运维。MySQL 的"装上就能跑"在这种场景里省掉了一个人头——这不是技术问题，是组织成本问题。
工程下限 2：高并发 OLTP 读性能稳
InnoDB 缓冲池 + 主从复制——读 QPS 上 10 万非常稳。电商首页 / 商品列表 / 用户中心这类写少读多场景，MySQL 的工程化做得比 PG 更成熟——索引优化器经验丰富、内存管理调优文档齐全、压测案例满地都是。
PG 在 OLAP 场景吊打 MySQL——但国内业务大多数是 OLTP + 高并发读，正好是 MySQL 的主场。
工程下限 3：Web 框架原生适配
国内主流业务系统的技术栈——Spring Boot + MyBatis + Druid 连接池 + ShardingSphere——这一套几乎全部以 MySQL 为一等公民。换 PG 不是不行，但：
ShardingSphere 对 PG 的支持远不如 MySQL 完整；
Druid 监控针对 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 的现成生态直接节省研发时间。
工程下限 4：云厂商深度优化（最容易被忽略）
阿里云 RDS / AWS RDS / 腾讯云 CDB——对 MySQL 的自动调优、备份、监控、读写分离、跨可用区高可用都做到了极致——一键部署、一键扩容、一键还原——完全不需要 DBA 介入。
PG 的云服务也在跟上——但国内云厂的 MySQL 文档 / 工具链 / SLA 比 PG 至少早 5 年。这是历史窗口期带来的不可逾越优势——你做 618 大促压测，云厂的 MySQL DBA 团队随叫随到；PG 团队你得等。
工程下限 5：招人速度——决定能不能扛住事故
这条最现实，也是最难量化的——你在国内招一个 MySQL DBA，简历投递量是 PG 的 5-10 倍。CSDN / Stack Overflow / 知乎上 MySQL 的问题答案体系新人友好度极高——遇到问题 5 分钟搜出来；PG 有时候要跑去英文社区翻原文档。
对一个团队来说"招人快 + 出问题查得快" 直接决定能不能扛过 P0 事故。这条不在技术对比表里，但在 CTO 心里排第一。
一张选型决策表：你这个项目该选谁
把上面所有判断收敛到一张可以照抄的表：
底层判断标准：**"这个业务的核心挑战是高并发还是复杂建模？"** ——前者选 MySQL、后者选 PG。两者都要，可能你需要的不是 MySQL 也不是 PG——是 NewSQL（TiDB / OceanBase）。
国产数据库为什么集体押注 PG
近年信创 + 数据库自主可控需求提升——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 落在哪里你能修得最快的那个。
欢迎加入我的知识星球，全面提升技术能力。
👉 加入方式，“长按”或“扫描”下方二维码噢：
星球的内容包括：项目实战、面试招聘、源码解析、学习路线。
文章有帮助的话，在看，转发吧。 谢谢支持哟 (*^__^*）