由 John Doe 十一月 11, 2026
这场 NoSQL 革命的标杆产品为何黯然退场？以及 “简历驱动开发” 背后的隐性成本。
目录
作者：Oz
想知道科技行业当年对 NoSQL 的炒作有多狂热，看《卫报》的两段历史就够了。
2011 年，《卫报》是 MongoDB 最耀眼的标杆客户。MongoDB 公司在各大技术峰会、演示文稿和企业案例中大肆宣扬这家英国媒体，将其奉为 “关系型数据库已死” 的铁证。所有内容（文章、实时博客、图库、视频元数据）都要迁到这款光鲜亮丽、“互联网级规模” 的无模式文档数据库里。
七年之后，《卫报》工程团队发布了一篇画风截然不同的文章：《告别 Mongo，拥抱 Postgres》。
在将 240 万篇文章、横跨二十年的新闻内容从 MongoDB 迁移到 PostgreSQL 后，他们彻底关停了自己的 NoSQL 集群。而这么做的远不止他们一家。放眼整个行业，成千上万支工程团队都在悄无声息地完成着同样的迁移。
当初承诺能让开发效率提升十倍的数据库，为何最终反而让团队耗费数月生产力、遭遇凌晨三点的惊魂故障，还要承担高昂的运维成本？
答案藏在有史以来卖给软件工程师最昂贵的谎言里：所谓 “无模式数据库” 的神话。
无模式的肮脏秘密
MongoDB 当初为什么能爆火？
不是因为每家十个人的初创公司突然都有了谷歌级别的非结构化数据，而是因为 MongoDB 把开发者营销玩到了极致。当 PostgreSQL 默默深耕 ACID 合规与查询优化器时，MongoDB 在校园黑客松上发周边，还给那些惧怕写 SQL 连接查询的开发者提供了一套类 JavaScript 的 API。
它的宣传极具诱惑力：别浪费时间设计数据表和外键了！直接把 JSON 扔进数据库，快速迭代就行！
但资深系统工程师很快就发现：世上根本不存在什么 “无模式” 的应用。
数据模式永远都存在。用无模式数据库，模式不会凭空消失，它只是从数据库引擎里（那里有四十年的数学校验与优化积淀）转移到了你的应用代码里。
不再由久经考验的关系型引擎来校验数据类型与约束，你的后端工程师不得不在几十个接口里写满防御性的 if/else 判断，只为确保用户记录里真的有邮箱字段。而一旦他们漏写了？数据库会毫无报错地吞掉脏数据，静静潜伏几个月，直到生产环境的批量任务突然崩溃。
阿布扎比沙漠的紧急电话：拆解《卫报》的退场之路
当《卫报》工程团队披露为何放弃 MongoDB、改用 PostgreSQL 承载核心内容管理系统（Composer）时，细节读起来就像每个基础设施工程师都耳熟能详的噩梦。
他们的数据集并非什么无法驾驭的大数据巨兽：大概 230 万条内容，服务数百名同时在线的编辑。但在 AWS 基础设施上维护 MongoDB 及其企业级管理套件（OpsManager），却成了一笔挥之不去的全职运维成本：
- 四万英镑的管理陷阱：出于严格的内容安全要求，《卫报》必须在自有 AWS VPC 内部署 MongoDB 和 OpsManager。Mongo 官方完全没有提供对应的自动化云工具。团队不得不手写数百行 Ruby 脚本和 CloudFormation 模板，只为管理这套 “管理工具”。更糟的是，由于认证模式出现破坏性变更，将 OpsManager 从 1 版升级到 2 版的复杂度极高，团队每年要花整整两个月的工程时间维护数据库部署，除此之外每年还要支付约 4 万英镑的 OpsManager 许可与技术支持费用。
- 沙漠惊魂故障：迁到 AWS 之后，《卫报》遭遇过两次严重的数据库故障，每次都导致
theguardian.com的内容发布完全中断超过一小时。两次危机中，无论是 OpsManager 还是 MongoDB 的付费技术支持人员都查不出问题。最终只能靠团队自己抢救生产环境，其中一次能撑过去，全靠他们的一位工程师在阿布扎比郊外的沙漠里接到了紧急电话，远程出手解决。 - 数据库逻辑泄露：等到终于决定迁移时，团队才发现根本没法简单替换存储层。MongoDB 特有的使用逻辑已经一路渗透到了 API 控制器的业务逻辑里，他们不得不从零搭建一套全新的 API（Scala 开发的 APIV2）和 Akka Streams 流量镜像代理，才能在不停服的前提下摆脱厂商锁定。
尘埃落定，团队将 DNS 切换到 PostgreSQL 后，他们的年度数据库成本降到了可预期的每年 1.3 万美元（RDS 托管），每年两个月的运维噩梦彻底消失，而所有编辑甚至都没察觉到系统已经切换。
简历驱动开发，与 30GB 的现实打脸
《卫报》的故事在 Hacker News 和 Reddit 上引发了大量资深工程师的共鸣与自爆。一个清晰的规律浮出水面：过去十年，行业做的根本不是数据工程，而是 简历驱动开发（RDD）。
工程师和管理者选择 NoSQL 数据库，不是因为关系型数据库扛不住负载，而是因为 “维护一台稳定可靠的 PostgreSQL 实例” 写在简历上，远不如 “架构设计多地域分布式 NoSQL 集群” 听起来光鲜。
这种心态带来的技术与财务损失触目惊心：
- 百万英镑堆出的六百万行集群：某主流财经媒体的一位资深架构师透露，一支 40 人的团队花了四年时间、耗资超百万英镑，在昂贵的物理服务器上搭建了一套 12 节点、多地域的 Cassandra 集群，而它存的不过是 600 万行基本只读的会员数据，这些数据放在一台 20 美元的 PostgreSQL 虚拟服务器的内存里都装得下。
- 50 倍的存储膨胀：由于文档数据库会在每份文档里重复存储字符串形式的字段名，还鼓励深度嵌套的数据结构，存储占用会急剧膨胀。有记录的一次生产迁移中，工程团队把一套占用 30GB 的 JSON 文档数据库做了规范化，存入类型严谨的 PostgreSQL 表中，最终整个数据集缩小到了 600MB，轻轻松松就能放进最小规格实例的内存里。
- 优化器优势：在 MongoDB 中，一旦数据访问模式变化，你就得手动用代码重写复杂的聚合管道。而在 PostgreSQL 里，你只需要写声明式的 SQL。哪怕三年间数据表从一万行增长到一亿行，PostgreSQL 的基于成本查询优化器也会自动调整执行计划，你一行应用代码都不用改。
JSONB 如何终结了这场战争
《卫报》迁移过程中最讽刺的转折，是他们迁移到 PostgreSQL 的方式。
他们甚至根本不用花几个月，把二十年杂乱的文章文档先规范化成严格的关系表。他们直接把文档原样存入了 PostgreSQL 的 JSONB 列类型。
当 PostgreSQL 推出二进制 JSON（JSONB），并支持 GIN（通用倒排索引） 与表达式索引后，它就彻底消解了独立文档数据库仅存的最后一点优势。
需要存储第三方 Webhook 或 CMS 编辑器传来的灵活、深度嵌套数据？放进 JSONB 列，给常用的查询路径建上索引，需要展开数组时用jsonb_array_elements就行。你能获得 MongoDB 承诺的全部文档灵活性 —— 而它就和你严格结构化的用户表、权限表放在一起，受真正的外键、完整的 ACID 事务，以及绝不会静默丢写的预写日志（WAL）保护。
写在最后
专用 NoSQL 引擎当然有其真实的适用场景。如果你要接入数千亿条短生命周期的广告技术遥测事件，或是部署最终一致性即可的全球分布式键值缓存，专用工具有其存在的价值。
但对于 99% 的软件系统来说，你的数据本质上都是关系型的。假装它不是并不会让你的架构更 “现代”，只会把你的应用代码变成一个 bug 百出、自制的数据库引擎。
《卫报》花了 10 个月的迁移工程、一通打去阿布扎比沙漠的电话，才换来这个教训。你不必重走弯路。
别为了简历设计你的数据库技术栈。用 PostgreSQL，在入口处就做好模式约束，真的需要文档场景就用 JSONB。凌晨三点值班的你，会感谢现在的决定。
参考与延伸阅读
- McMahon, P., Chiorean, M., Coleman, S., & Askoolum, A. (2018). 《告别 Mongo，拥抱 Postgres》. 《卫报》工程博客.（Composer CMS 系统 240 万篇文章从 MongoDB+OpsManager 迁移至 PostgreSQL JSONB 的完整复盘）
- MongoDB 公司案例库 (2011). 《我们为何为 < 卫报 > 选择 MongoDB》.（《卫报》最初选用 NoSQL 的历史背景）
- Kingsbury, K.（Jepsen 测试系列）. 《MongoDB 因果一致性与分片集群分析》. Jepsen.io.（针对网络分区下写入安全保障与数据丢失边界场景的实证测试）
- PostgreSQL 全球开发组. 《JSON 类型（json 与 jsonb）与 GIN 索引策略》. PostgreSQL 官方文档
- 《卫报》工程团队问答（Hacker News 主题帖 #18717174）. 运维成本拆解（4 万英镑 OpsManager 开销对比 1.3 万美元 PostgreSQL 部署）与生产故障分析