PostgreSQL 正在悄悄"杀死" MongoDB，而你可能还在听那些过时的技术博客选型...
一次价值3200万的选型失误
2025年12月，某头部电商大促夜。
凌晨00:47，订单系统开始出现延迟告警。00:52，主库CPU打满。00:58，服务全面雪崩。
47分钟后恢复，直接损失3200万。间接损失？品牌信誉、用户流失、团队连夜加班的精神损耗……无法估量。
事后复盘的结论只有一句话：
他们选了 MongoDB，但数据模型却是高度关联的订单-商品-库存三级联动。
这不是个例。过去一年，我参与审计过13个生产事故，其中9个根因都是——数据库选错了。
更可怕的是，这些决策往往不是技术问题，而是认知问题。
那些网上铺天盖地的「MySQL vs MongoDB」对比文章，90%都在误导你。
你以为的选型 vs 真正的选型
❌ 大多数人的选型逻辑：
"我们项目要用文档存储，所以选 MongoDB"
"我们要高性能，所以选 MySQL"
"PostgreSQL？太重了吧，不熟悉"
这不是选型。这是刻板印象。
✅ 真正的选型逻辑：
在2025年，MySQL、PostgreSQL 和 MongoDB 的边界早已模糊到让人窒息：
- PostgreSQL 的 JSONB 能力和 pgvector 插件，让它成为了"文档数据库+向量数据库+关系型数据库"的三合一怪兽
- MongoDB 引入了多文档 ACID 事务，想攻占传统交易场景
- MySQL 通过 Vitess 中间件，实现了超越传统 NoSQL 的水平扩展
还在用2018年的认知选型2026年的系统？这就是踩坑的根源。
深入骨髓：三者的本质差异
在比较功能之前，先问自己一个灵魂问题：
你的数据是怎么流动的？
这个问题的答案，决定了你该选谁。
MySQL：以索引为王的存储哲学
InnoDB 的核心设计是「索引组织表」——数据就是主键索引本身。
这意味着：
- 主键查询只需一次B+树遍历，效率极高
- 所有辅助索引存的是主键值，查询需要「回表」（两次查找）
- 对缓存极其友好，因为相关数据物理上紧凑存储
适合场景：你的业务 80% 是主键查询（用户中心、订单表、Session存储）
致命陷阱：双写缓冲机制导致高并发写入时吞吐量有硬顶
PostgreSQL：解耦的优雅与膨胀的代价
PostgreSQL 的「堆存储」架构完全不同——数据存在无序的堆文件中，索引只存指针。
核心特性：
- 主键和辅助索引结构一致，性能均衡
- MVCC 实现是「追加写」——更新时不原地改，而是写新版本、标记旧版本过期
- 需要 Vacuum 进程清理旧数据，配置不当会导致表膨胀
适合场景：复杂的辅助索引查询 + 需要JSON灵活性 + AI向量搜索
致命陷阱：高频更新（如计数器）会让 Vacuum 压力爆炸
MongoDB：文档模型的自由与枷锁
WiredTiger 引擎专为文档设计，BSON 格式让数据天然带结构。
核心特性：
- 一次 I/O 读取完整文档，无需 JOIN
- 块级压缩效率惊人（Snappy/Zstd）
- 写时复制 + 检查点机制保证持久性
适合场景：层级化数据、多态结构、读多写少的内容管理
致命陷阱：BSON 存储键名导致空间膨胀；$lookup（类JOIN）性能远不如 SQL
并发控制：魔鬼藏在细节里
这是大多数选型文章不敢讲透的部分。
PostgreSQL 的优势：真正的可串行化隔离
PostgreSQL 的 SSI（可串行化快照隔离）能检测「写偏斜」等复杂异常，在不加锁的情况下保证串行化一致性。
如果你在做金融交易系统，PostgreSQL 的 SSI 是理论上的最优解。
MySQL 的陷阱：悲观锁的性能天花板
InnoDB 的 REPEATABLE READ 通过「间隙锁+行锁」防止幻读。这是悲观策略。
高并发写入场景下，锁竞争和死锁是家常便饭。
MongoDB 的真相：事务不是救命稻草
MongoDB 4.0+ 支持多文档 ACID 事务，但有物理限制：
- 单事务 oplog 条目有大小限制
- 跨分片事务的性能损耗巨大
MongoDB 的设计哲学是「避免事务」——通过内嵌文档设计，让原本需要跨表的操作在单文档内完成。
如果你的业务逻辑天然需要跨十几张表的复杂事务编排（如ERP），强行用 MongoDB 事务，等于自己给自己挖坟。
扩展性：当你撞上单机天花板
方案
原理
门槛
适用场景
MongoDB 原生分片
Mongos 路由 + Config Servers + Shards
中
开箱即用，接受非关系模型
MySQL + Vitess
VTGate 智能路由 + VTTablet 边车
极高
超大规模 C 端应用（YouTube、Slack级别）
PostgreSQL + Citus
协调节点 + 工作节点
中高
B2B SaaS 多租户场景
警告：MongoDB 分片选错 Shard Key 会导致热点问题——所有写入集中在一个分片，集群性能退化为单机水平。别问我怎么知道的。
GenAI 时代的新变量：向量搜索
2026年，数据库不再只是存数据的仓库，更是 AI 应用的知识库。
PostgreSQL + pgvector = 杀手级组合
在同一个数据库中同时存储：
- 业务数据（用户、订单）
- 向量嵌入（Embeddings）
一个 SQL 查询完成：元数据过滤 + 语义搜索
避免了 Pinecone 和 PostgreSQL 之间的数据同步噩梦
MongoDB Atlas Vector Search
与文档模型天然契合，向量作为字段直接存文档里。
但强依赖 Atlas 云服务，私有化部署受限。
终极决策树：告别选型焦虑
场景一：选 PostgreSQL（约70%的项目）
- ✅ 核心交易系统（银行、支付、账务）
- ✅ 复杂 B2B SaaS（多租户、动态权限）
- ✅ 数据一致性至上（不能容忍最终一致性）
- ✅ 混合负载（结构化 + JSON + AI向量）
- ✅ 地理信息系统（PostGIS 无敌）
场景二：选 MongoDB（约20%的项目）
- ✅ 快速迭代的 C 端应用（Schema 每天都在变）
- ✅ 内容管理与目录系统（多态属性）
- ✅ 海量日志与 IoT（只需最终一致性）
- ✅ 移动端离线同步（MongoDB Realm）
场景三：选 MySQL（约10%的项目）
- ✅ 简单高并发读（KV 查询、Session 存储）
- ✅ 团队有深厚 MySQL 运维经验
- ✅ 极端规模分布式（配合 Vitess，但门槛极高）
一句话总结
选型不仅仅是选择一个软件，更是选择一种数据治理的哲学。
PostgreSQL 凭借其全能性（Relational + JSON + Vector + GIS），已成为大多数新项目的默认「安全选项」。
MongoDB 是处理非结构化数据的「特种武器」，而非「通用锤子」。
MySQL 退守高性能 OLTP 和超大规模分布式领域。
架构师应透过特性的迷雾，洞察业务数据流动的本质，做出最符合业务生命周期的决策。
否则，凌晨3点的告警电话，会替你做复盘。
转发这篇文章的人，想表达的是：「看，这才是技术决策的深度思考。」