为什么MongoDB是一条架构死胡同

每一代技术都在寻求以更少的复杂性更快发展的捷径。但一次又一次，这些捷径并非真正的捷径。相反，它们推迟了那些必须经过深思熟虑才能做出、并且需要付出巨大代价才能撤销的艰难抉择。在2010年代，MongoDB就是这样一个捷径。

当公司需要快速启动并拥有灵活选项时，MongoDB似乎很有道理。以Mechademy为例，该公司为一些全球最大的石油、天然气和能源公司监控资产。Mechademy最初选择MongoDB来构建数字孪生（用于优化性能的物理资产的虚拟表示）。MongoDB允许在不受到严格模式约束的情况下，对不断变化的数据结构进行快速迭代。结合MERN技术栈，Mechademy能够快速行动，快速原型化想法，并专注于数据编排而非数据库设计。

但这种灵活性带来了不可预测的成本，因为它带来了技术债务。随着Mechademy规模的扩大，数据模型本身成了瓶颈。各种变通方案导致了深度嵌套的聚合管道，这些管道变得越来越脆弱且运行成本高昂。当初因能实现快速灵活迭代而选择的技术，现在需要不断调优和维护才能保持性能。

随着Mechademy诊断工作负载的扩展，MongoDB的资源利用率急剧飙升。即使是每小时处理约10,000个测试的小型租户，其CPU利用率也持续高于95%。每一项新的诊断功能都需要更复杂的查询和更高的性能阈值，导致了一个不可持续的扩展和重新设计周期。

MongoDB最初提供的自由，最终变成了一个陷阱。

01 无结构灵活性的陷阱

MongoDB的NoSQL无模式设计起初让人感觉自由。随时添加字段。无需迁移即可更改数据类型。跳过前期设计，毫无阻力地推进。

但文档会漂移，类型会分化，查询会变慢。最初感觉到的速度，后来会变得脆弱，直到生产环境调试变成在JSON数据块中挖掘，而性能调优则像是一场猜谜游戏。

当集合是孤立且无类型时，数据无法复合。每个数据集都变成了自己的孤岛。相比之下，Postgres使用模式和关系，使得数据在一起比分开更有价值。这就是为什么SQL查询可以随着时间的推移变得更加复杂，而MongoDB查询常常因其自身重量而崩溃。

灵活性总是有代价的，这可能表现为未定义的技术债务或意外的运维负担。你可能不知道代价有多大，也不知道何时需要支付，直到为时已晚。

02 临时附加本应核心的功能

为什么使用MongoDB扩展如此具有挑战性？每当市场需求新功能时，MongoDB都选择附加功能，而不是开发新的核心基础更新，这使得实施和扩展变得越来越复杂。

让我们看看MongoDB方法的几个例子：

• 事务处理：在关系型系统完善事务处理几十年后，MongoDB才添加此功能。MongoDB中的事务处理确实有效，但其性能代价使得它们在实际的高负载工作场景中并不实用。
• 分析：MongoDB的聚合管道在演示中看起来很整洁。在实际工作负载中，它们冗长且脆弱，由数百行转换逻辑组成，一旦文档形状发生变化就会崩溃。团队最终不得不将数据导出到Spark、数据仓库或自定义管道中，仅仅是为了回答问题。
• 时间序列：MongoDB宣传“时间序列集合”，但实际上，这些集合不过是对文档存储的修补。压缩能力弱。保留策略是手动的。没有类似于增量物化视图的功能。
• 可观测性：搜索和图功能也被叠加进去，但都是在一个并非为其设计的架构之上。结果是在实践中无法深度扩展的表面功能。
• 查询语言：MongoDB查询语言（MQL）将你锁定在一个只有受过MongoDB培训的团队才能使用的自定义语法中，而不是鼓励跨团队协作使用标准的SQL来执行跨不同数据库的复杂查询。

每一项都是为了满足特定的客户需求而打的补丁，而不是一个为架构扩展而构建的数据库。在融合的关系型/分析型环境中，NoSQL没有未来。MongoDB可以添加功能，但它无法改变其核心架构并非为现代工作负载设计这一事实。

03 运维负担 vs 运维便捷

MongoDB的真正成本不仅仅是性能痛苦，还包括大规模运行它所带来的持续负担。MongoDB遭受索引膨胀、持续聚合维护以及因功能是附加而非内置设计导致的风险升级之苦。随着时间的推移，你的团队花费在保持MongoDB运行上的精力将超过构建产品本身。

随着时间的推移，你的团队花费在保持MongoDB运行上的精力将超过构建产品本身。

这不仅仅是理论上的。Infisical，一家快速增长的安全初创公司，每天处理数千万个密钥，于2024年从MongoDB迁移到了Postgres。他们提到MongoDB副本集和跨环境版本不一致带来的运维难题是推动其迁移的原因，而这些问题在切换到Postgres后便消失了。迁移不仅提高了可靠性；还使数据库成本降低了近50%。

相比之下，Postgres的规模越大，运行就越容易。复制、备份和故障转移变得简单，而“简单”正是你对运维数据库的期望。数十年的成熟意味着操作手册已知，工具丰富，并且每个云提供商都提供一流的托管Postgres服务。

数十年的成熟意味着操作手册已知，工具丰富，并且每个云提供商都提供一流的托管Postgres服务。

在大规模场景下，MongoDB创造工作。Postgres则消除工作。

04 PostgreSQL：一个复合价值的基础

Postgres讲述了一个不同的故事。它始于纪律：关系模式、ACID事务和成熟的查询规划器。这种纪律成为了数十年社区驱动的演进的基础，这些演进由其用户的需求驱动。

随着时间的推移，Postgres并没有附加功能。相反，它优雅地吸收了它们：

• JSONB：用于无混乱的文档存储。
• PostGIS：用于地理空间工作负载。
• pgvector：用于AI和嵌入。
• 超表（Hypertables）、压缩以及TimescaleDB创建者Tiger Data提供的连续聚合：用于时间序列和实时分析。

其结果是一个能够复合价值的架构。MongoDB的捷径推迟了严谨性并迫使痛苦的重构，而Postgres则实现了稳定的扩展，并提供了一个能够随数据和不可预测的行业变化而扩展的平台。

而且不仅仅是技术——还有社区：Postgres拥有全球最活跃、最受信任的开源社区之一。成千上万的贡献者年复一年地推动其发展，围绕它成长起了一整个公司生态系统。这种复合式的创新并非来自供应商路线图。它来自于关心并深度投入到为其公司和客户打造最佳技术栈的开发人员。

这就是为什么Mechademy选择了带Tiger Data的托管Postgres。该平台实现了：

• 原生时间序列支持：超表消除了手动分桶和模式维护，自动按时间和空间分区数据。
• 连续聚合：自动汇总提供了多种分辨率的数据，完美适用于具有不同时间范围的诊断测试。
• 内置压缩：在提升查询性能的同时，大幅降低了存储成本。
• 统一的SQL + Postgres熟悉度：使用标准、成熟的查询语言简化了入门、调试和开发。

效果是立竿见影且变革性的。数据说明了一切：

• 基础设施成本降低87%
• 工作负载容量增加50倍（从每半小时20万次测试增加到1000万次测试）
• 使用超表和压缩，维护开销几乎为零
• 统一事务型+分析型工作负载，无ETL复杂性
• 可预测的性能扩展和极大简化的运维

这就是为什么Postgres已悄然成为现代时代的默认数据库。它不是由炒作驱动的。它是由基础驱动的。

05 基准测试中的PostgreSQL与MongoDB

基准测试用数字使架构变得可见。当Postgres和MongoDB并排测试时，故事是一致的：Postgres在大规模下更快、更可预测、更高效。

• 事务处理（OLTP）：在OnGres/EnterpriseDB进行的正面比较中，Postgres以显著优势胜过MongoDB。在事务密集型工作负载下，Postgres实现了4到15倍的更高吞吐量，中位延迟低于10毫秒，第99百分位延迟低于50毫秒。相比之下，MongoDB的中位延迟慢5到20倍，尾部延迟慢高达17倍。
• 分析和实时查询：在用于实时分析的开源基准测试套件RTABench上，当数据集增长到数百万行时，Postgres始终比MongoDB提供更低的查询延迟和更高的吞吐量。在MongoDB中需要数秒才能完成的复杂过滤和聚合，在Postgres中几毫秒内即可返回，这反映了Postgres基于成本的规划器和成熟的索引策略。
• 半结构化数据：考虑到其架构，MongoDB本应在半结构化数据方面拥有巨大优势。但DocumentDatabase.org最近比较PostgreSQL 16.1和MongoDB 7.0.3的基准测试发现了一个微妙的情况：
  • Postgres在批量加载方面略有优势，并且在单条插入方面明显更快。
  • 单条插入：Postgres比MongoDB快得多。
  • 存储：由于压缩，MongoDB在空间效率上更高。
  • 查询：在小规模下Postgres更快，但当数据集增长超过约50万行时，MongoDB能保持更稳定的性能。
  • 结论：Postgres在JSON性能方面已经缩小了差距，甚至在插入和小型工作负载方面超过了MongoDB，而MongoDB在存储效率和超大型纯JSON查询方面仍保持优势。

MongoDB在某些场景下仍然出色：其仅追加设计和可调一致性意味着，当不需要一致性和索引时，它可以以非常高的吞吐量摄取简单的JSON文档，通常比Postgres快。对于原始遥测或日志捕获，MongoDB可能看起来很有吸引力。然而，一旦工作负载超出了插入操作，当需要查询、连接、分析或可靠的事务时，Postgres的表现始终优于MongoDB。

在规模化场景下，差距显而易见

• OLTP：Postgres = 吞吐量快4–15倍
• 分析：毫秒级 vs 秒级
• 可预测性：Postgres延迟保持平稳；MongoDB随增长而变慢

基准测试证实了架构所预测的：当你成功时，MongoDB变慢。Postgres则随你一同扩展。

06 架构死胡同的战略成本

这里有一个真正的教训：数据库的选择不仅仅是技术性的。它们是战略性的。

MongoDB让你快速起步。但在规模上，它会让你慢下来。成本不仅仅体现在基础设施账单上。它还体现在因处理技术债务而错失的创新机会上。

Postgres颠覆了这个剧本。你使用它的时间越长，它就变得越强大。生态系统在增长。扩展功能在增加。你可以在没有技术债务拖累的情况下进行扩展。

开发人员知道这一点。在2025年Stack Overflow开发者调查中，Postgres连续第三年被全球开发者评为最受推崇的数据库。行业已经标准化于Postgres，而NoSQL的受欢迎程度持续下降。

07 未来属于复合型架构

MongoDB是一条架构死胡同。它从未被设计成一个运维数据库。它建立在一个狭隘的时刻，当时网络应用重视快速原型设计胜过长期可扩展性。在融合的关系型/分析型环境中，NoSQL的复杂性没有未来。

Postgres讲述了一个相反的故事。它之所以成为默认的运维数据库，恰恰是因为它既灵活又有纪律，既能处理事务又能进行分析，既可靠又可扩展。它具备复合价值。

如果你在为未来构建，不要选择一条死胡同。建立在一个基础上。建立在Postgres上。

MongoDB是上一个时代的捷径。Postgres是下一个时代的基础。