科技巨头为何悄悄放弃这位 NoSQL 王者？你的公司，又在为复杂性付出多少代价？原文给出的数字是500万美元。

看看2026年那些顶尖科技公司的数据架构，你会发现一个值得留意的变化：它们已经不再热衷于炫耀自己横向分片的 MongoDB Atlas 集群。

相反，它们开始悄悄删除 Mongoose 模式定义，拆掉文档存储系统，重新走回关系型数据库的路线。

十多年来，MongoDB 一直是现代应用开发中备受追捧的数据库。MERN 技术栈的流行，加上硅谷的推崇，让一套说法深入人心：关系型数据库是过时的老古董，只有把数据都装进灵活的 JSON 文档里，开发才能足够快。如今，热潮退去，后遗症开始显现。越来越多团队发现，MongoDB 也可能变成一笔庞大、持续且难以摆脱的复杂性成本。

颇有意味的是，图灵奖得主、数据库先驱 Michael Stonebraker，早在十五年多前，就提醒过人们警惕这类架构陷阱。

警告：虚假的灵活性

NoSQL 热潮最盛的时候，开发者对“无模式数据库”充满期待：不必提前考虑表结构、外键和迁移，只要把非结构化 JSON 放进集合，似乎就能直接开工。

Michael Stonebraker 对此持强烈批评态度。他在2010年发表于《Communications of the ACM》的文章中，讨论了放弃关系结构和 SQL 的问题。其批评可以概括为：

在数据库层放弃模式和关系引擎，并不会消除复杂性，而是把工作推给应用开发者，迫使他们在业务代码里重新实现一个临时拼凑、容易出错的数据库引擎。你想得到的灵活性，很可能只是虚假的灵活性。

这恰好对应了 MongoDB 使用过程中容易出现的一类危机。

工程团队把用户、订单、发票、权限这些天然存在关联的业务数据，拆成一个个独立的 JSON 文档。当数据库没有承担相应的结构约束时，开发者就得在 Node.js 或 Python 中补上大量校验逻辑。等产品经理提出跨集合分析的需求，团队又可能撞上 $lookup 的性能瓶颈。接下来，为了搜索引入 Elasticsearch，为了同步数据再接入 Kafka，最后还要编写后台脚本，清理异常数据和失去关联的孤立文档。

原本应该在前期完成的结构设计，被换成了长期存在的应用层复杂性。而后者，往往贵得多。

声望税与大规模出走

MongoDB 被推广为应对互联网规模非结构化数据的方案。但现实中，很多公司的数据并没有那么“非结构化”，只是把关系明确的业务记录，换成了 JSON 的外形。

一家成长中的初创公司采用 MongoDB Atlas，并不意味着它就获得了无限的开发敏捷性。有时，它只是为流行的技术选择付了溢价。随着数据增长，WiredTiger 索引的内存需求不断增加，云账单可能涨到每月数万美元。工程师则把大量迭代时间花在排查数据不一致上，而其中一些问题，本可以通过一条 SQL FOREIGN KEY 约束提前避免。

这种担忧并非全无现实依据。原文列举了几家离开 MongoDB 的工程团队：

• 《卫报》：在媒体技术领域一次受到广泛关注的基础设施调整中，《卫报》将核心内容管理平台从 MongoDB 迁移到了 PostgreSQL。即使它存储的是数百万篇文章文档——看起来很符合文档数据库的典型用途——运维负担、硬件成本和排障难度，仍然推动团队回到关系型架构，并实现了零停机迁移。
• Diaspora 的 NoSQL 退出：这个曾备受关注的去中心化社交网络，最初将平台建立在 MongoDB 上。随着用户关系增多，通过文档引用遍历社交关系，带来了严重的延迟和内存问题。团队在复盘中指出，社交数据本身具有很强的关系属性，最终将平台迁回 SQL 数据库。
• Olery 与 Shippo 的迁移：Olery、Shippo 等成长型平台，也公开讨论过离开 MongoDB 的经历。当业务走到需要处理复杂关系的阶段，结构约束不足，以及应用层关联查询的成本，开始影响产品可靠性和工程效率。

无模式幻想的隐性成本

应用越成熟，这笔复杂性成本就越难忽视。

事实上，不存在真正不需要数据模式的应用。业务代码始终需要理解字段的类型、含义和关系。如果没有在数据库中明确实施这些约束，它们就会散落在应用代码里。假如一个开发者不小心把价格字段从 integer 写成了 string，而系统又没有配置对应校验，这条数据就可能被接受。六个月后，财务报表流水线凌晨三点崩溃，团队才发现，数百万份文档已经混用了三种格式。

硬件开销也是问题的一部分。文档会重复存储字段名称，其存储结构与成熟关系引擎的紧凑行记录不同。在高写入负载下，具体的数据模型、压缩和索引设计，都可能让 I/O 与内存成本迅速增加。

一些基础设施团队因此开始重新整合工作负载，将它们放到经过充分优化的 PostgreSQL 部署中，采用裸金属服务器或专用实例，再借助 Percona Monitoring and Management（PMM） 等可观测性工具检查查询计划、调整内存缓冲区、优化磁盘 I/O。他们希望用更可控的基础设施成本，获得严格的 ACID 事务保障。

什么会取代王者？

MongoDB 不会明天就消失。对于相对独立的产品目录，或者只需要快速验证、用完即可丢弃的黑客松原型，它依然有适用空间。

但把它当作现代初创公司的默认主数据库，已经越来越值得重新考虑。为了摆脱文档模型与关系型业务之间的摩擦，开发者正在关注两个方向：

1. 支持 JSONB 的 PostgreSQL（全能数据库）：MongoDB 面临的一个重要挑战，是 PostgreSQL 已经能够承接它最吸引人的一部分用途。通过原生 JSONB 支持和 GIN 索引，开发者可以把 JSON 文档与严格定义的关系表放在同一个数据库里，完成存储、索引和查询，同时保留 ACID 事务能力。在合适的工作负载中，它也可能获得更好的性能。
2. 现代无服务器与嵌入式 SQL：如果开发者喜欢 MongoDB，主要是因为配置快、上手省事，那么 Supabase、Neon，以及面向边缘场景的 SQLite（Turso） 等方案，也提供了低配置门槛的 SQL 使用体验，不必因此放弃关系型数据的完整性。

启示

MongoDB 缓解了第一天搭建数据库的阻力。但如果团队忽略了约束和数据治理，也可能在第一百天遇到更昂贵的问题：数据已经不再一致。

Stonebraker 的提醒值得重视。为了少写一条 CREATE TABLE，就忽略关系型数据库几十年积累下来的设计经验，未必划算。当你花在应用层关联查询、修复异常 JSON 数据上的时间，已经超过开发功能的时间，这套架构带来的负担，就需要重新评估了。

2026年，真正值得关注的 CTO，或许不再是那些炫耀 NoSQL 分片集群的人，而是那些重新检查业务需求，并悄悄迁回 SELECT * FROM 的人。

阅读原文：点击这里​