MongoDB碰瓷PG？好营销救不了烂产品！
这两天 MongoDB 整的营销花活让人眼花缭乱：《MongoDB向PostgreSQL宣战》，《MongoDB 击败 PostgreSQL 赢下价值 300 亿美元项目》，以及原文 The Register 的《MongoDB在战胜强敌之后准备乱拳干翻 PostgreSQL》。有些朋友得意洋洋的特意转给我看，想看 PG 的笑话，这着实让我感到无奈 —— 这么离谱的新闻都有人信。
把东西卖给估值300亿的公司，和做 300 亿的项目完全是两码事。要按这种说法，苹果密集使用了 PostgreSQL 数据库，也采购 Cybertech 的PG服务，那也没见 Cybertech 吹这种牛逼我们赢得了个值 3500B（公司）的订单。
但事实却是 —— **这么离谱的东西真的就有人信！**包括某些 CEO 也照样中招翻车。当然，这不能怪人家眼拙，这是 MongoDB 在营销上的一贯伎俩 —— 如果不仔细看原文，很难区分这个 300 亿指的是项目，还是还仅仅是这个公司的估值。
在 2024 年，MongoDB 在产品和技术上都乏善可陈；在正确性，性能，功能以及各种维度上被 PostgreSQL 按在地上摩擦吊打；DB-Engine 热度持续走低，在开发者中的流行度与口碑都不断下滑，MongoDB 公司本身也不挣钱，亏损继续扩大，股价也刚经过减半大腰斩。“营销” 也许是 MongoDB 唯一能拿出手的东西了。
图灵奖得主，数据库祖师爷 Stonebraker 老爷子在最近在 SIGMOD 2024 发表的名著级论文《What goes around comes around… And Around》中对此有过精辟的评价：“绝对不要低估好营销对烂产品的影响 —— 比如 MySQL 与 MongoDB”。
如果 MongoDB 在自己的一亩三分地自嗨，也没人稀得去理他。但如果它非要跳出来用这种恶劣的营销来碰瓷 PostgreSQL 找打 —— 那么求锤得锤，也不要怪别人喷它。所以今天，我就和大家一起扒一扒，这个丝绸被套里装的都是什么烂棉花。
满篇的忽悠与春秋笔法
这个世界上有许多烂数据库 —— 但能用三寸不烂之舌把烂货成功吹成宝贝的，套用石破天老爷子的评价，MongoDB 说自己是第一，MySQL 也只能屈居人下。
在所有关于 MongoDB 谎话的故事中，最让人印象深刻的是发表在 LinkedIn 上的这一篇《MongoDB 3.2 —— 现由 PostgreSQL 强力驱动》 这篇文章的精彩之处在于，它是由 MongoDB 合作伙伴发出的血泪控诉：MongoDB 对在生态中做分析的伙伴不屑一顾，而是跑去拿了一个 PostgreSQL 作为自己的分析引擎，并在发布会上忽悠用户，从而让合作伙伴彻底灰心丧气，将此事抖落出来。
像这样的春秋笔法甚至刻意造假的案例绝非个例，MongoDB 还在贬低同业产品自抬身价上有诸多记录。例如在官网的文章《从PostgreSQL迁移到MongoDB》中，MongoDB 宣称自己是 “可扩展灵活的新一代现代通用数据库”，PostgreSQL 是 “复杂且容易出错旧的单片关系数据库”。完全无视了其实自己在整体的性能，功能，正确性，甚至自己标榜的应对大数据量的吞吐与可伸缩性上完全被 PostgreSQL 吊打的事实。
正确性与性能被吊打
一塌糊涂的正确性
对于数据库来说，最核心的要素永远是正确性 —— 中立的分布式事务测试框架 JEPSEN 对 MongoDB 的正确性做过评测：结果基本上可以用 “一塌糊涂”来形容（BTW：另一个被 JEPSEN 评为一塌糊涂的数据库是 MySQL）。
当然，MongoDB 的强项就是面不改色心不跳的 “忽悠“，尽管 JEPSEN 提了这么多的问题，在 MongoDB 官网上，关于 Jespen 的评测是这么介绍的：”到目前为止，因果一致性通常仅限于研究项目……MongoDB 是我们所知的第一个提供实现的商业数据库之一“ —— 堪称“语言艺术大师”，从一大坨臭狗屎中精心挑选出了一颗未消化的花生米，而只字不提在正确性/一致性上的各种致命硬伤。
按在地上摩擦的性能
作为一个专用的文档数据库，性能应当是其相对于通用数据库的安身立命之本。先前，有一篇《从 MongoDB 到 PostgreSQL 的大迁移》引发了 MongoDB 用户的关注，我的用户群里有位朋友 @flyingcrp 问了这样一个问题 —— 为什么PG上的一个插件或者功能点就能顶的上别人一个完整的产品？
当然也有持相反观点的朋友 —— PG的 JSON 性能肯定比不过细分领域的专业产品 —— 一个专用数据库如果连性能都干不过通用数据库，那还活个什么劲儿？这个讨论引起了我的兴趣，这些命题成立吗？
于是，我做了一些简单的检索与研究，结果发现了一些非常有趣且震惊的结论：例如，在 MongoDB 的看家本领 —— JSON 存储与检索性能上，PostgreSQL 已经吊打 MongoDB 了。来自 ONGRES 与 EDB 的一份 PG vs Mongo 性能对比评测报告 详细对比了两者在 OLTP / OLAP 上的性能，结果一目了然。
另一份更近一点的性能对比 着重测试了 JSONB / GIN 索引下的表现对比，得出的结论也是：PostgreSQL JSONB 列是 MongoDB 的替代品。老实说，MongoDB 的性能已经完全跟不上时代了 —— 而它引以为傲的“内置分片”可伸缩性，在软件架构与性能突飞猛进，硬件遵循摩尔定律指数发展的当下，显得一文不值。
被覆盖向下兼容的功能
PostgreSQL 不仅在性能上吊打 MongoDB，而且在功能上也覆盖向下兼容了 MongoDB。PostgreSQL 生态中的 FerretDB 项目通过中间件的方式，在 PostgreSQL 集群上实现了 MongoDB 线缆协议兼容性 —— MongoDB 的应用都不需要更换客户端驱动，修改业务代码就能迁移到 PostgreSQL 上（另一个被PG线缆兼容的是 SQL Server ）。
另一个当前非常火热的项目是 PongoDB，则是直接在 NodeJS 客户端驱动侧将 PG 仿真成一个 MongoDB，这简直是釜底抽薪，直接掀翻了 MongoDB 的饭桌。
MongoDB不是开源软件，也没有生态
更不用提 MongoDB 已经不是一个开源软件了。MongoDB 原本使用 AGPLv3 时还算是开源项目，然而在 2018 年之后使用 SSPL 后就不算开源软件了。相比之下，使用 BSD Like 协议的 PostgreSQL 在友善度和成本维度上简直就是将 MongoDB 按在地上摩擦。
MongoDB 没有生态
在那个时间点，我确实还不曾知道竟然有这样的轶事。但几乎在同一时间，我也在负责进行一个从 MongoDB 到 PostgreSQL 的大迁移项目。我们部门先前用 MongoDB 搭建了一套实时统计平台，存放全网应用下载/安装/启动计数器，几 TB 规模的数据。我负责把这套在线业务的 MongoDB 迁移到 PostgreSQL。
很巧的是，我也使用了这种基于 Multicorn 编写自定义 FDW 的方法，将 MongoDB 的数据抽取到 PostgreSQL 进行进一步分析加工，还水了一篇论文。
Wang, X., Feng, R., Dong, W., Zhu, X., & Wang, W. (2017). Unified Access Layer with PostgreSQL FDW for Heterogeneous Databases. In IFIP International Conference on Network and Parallel Computing (pp. 131-135). Springer, Cham. Lecture Notes in Computer Science, vol 10578
总的来说，我对 MongoDB 绝对不陌生，但在这个过程中，我对 MongoDB 留下了极差的印象 —— 我花费了很多时间清洗 MongoDB 中模式错乱的垃圾数据。包括一些匪夷所思的问题（比如 Collection 里有整本的小说，SQL 注入的脚本，非法的零字符、Unicode码位与Surrogate Pair，各种花里胡哨的模式），堪称是一个史诗级的垃圾箱。
我认为 MongoDB 的模型极其简陋，查询语言的品味也极为恶劣，而且在业界也产生了非常糟糕的影响。真正让我纳闷的是：这么拉的数据库，为什么还活着？答案可能就在其“营销”之中 —— 如果不是刻意捏造事实撒谎，也少不了精心编排观点以实现故意误导。
我对 MongoDB 并不陌生 —— 上一次和 MongoDB 打交道是在 2016 年。我们部门先前用 MongoDB 搭建了一套实时统计平台，存放全网应用下载/安装/启动计数器，几 TB 规模的数据。我负责把这套在线业务的 MongoDB 迁移到 PostgreSQL。
在这个过程中，我对 MongoDB 留下了极差的印象 —— 我花费了很多时间清洗 MongoDB 中模式错乱的垃圾数据。包括一些匪夷所思的问题（比如 Collection 里有整本的小说，SQL 注入的脚本，非法的零字符、Unicode码位与Surrogate Pair，各种花里胡哨的模式），堪称是一个史诗级的垃圾箱。
在这个过程中，我也深入研究了 MongoDB 的查询语言，并将其翻译为标准 SQL。我甚至使用 Multicorn 写了一个 MongoDB 的外部数据源包装器 FDW 来做到这一点，顺便水了篇 Paper。
Wang, X., Feng, R., Dong, W., Zhu, X., & Wang, W. (2017). Unified Access Layer with PostgreSQL FDW for Heterogeneous Databases. In IFIP International Conference on Network and Parallel Computing (pp. 131-135). Springer, Cham. Lecture Notes in Computer Science, vol 10578
总体来说，我认为 MongoDB 的模型极其简陋，查询语言的品味也极为恶劣，而且在业界也产生了非常糟糕的影响。
首先，MongoDB 公司被发现在性能方面大量撒谎。
然后人们发现该产品的数据质量也很差。
然后人们发现“无模式”实际上意味着你拥有数百万个模式。
然后人们发现MongoDB的报告子系统实际上是一个嵌入式的Postgres数据库。
然后人们发现缺乏连接实际上是一个巨大的问题。而且在繁忙的 MongoDB 集群上回填旧数据可能需要数周时间。
最后人们发现，在存储 json 的一系列基准测试中，Postgres 比 MongoDB 更快。
因此，从这一点来看，MongoDB 就像 NoSQL 世界中的 MySQL：有太多谎言、太多夸张、太多坏建议。我们中的许多人都希望永远不再看到 mongodb。
学习如何有效使用文档数据库并不需要成为营销部门的鹦鹉。这意味着了解优势、劣势和设计模式：
数据质量：当 mongodb 复制不是原子的并且您可以覆盖部分记录时 - 您会怎么做？
无模式：实际上意味着“数百万个模式”——每行可能包含不同类型的不同字段。或者您很严格，坚持使用单一模式，并频繁进行模式迁移。这违背了公司的建议，违背了他们的“无模式”公关，并且在大型数据库上可能需要很长时间。
连接：是一种非常强大的适应性功能。最终，大多数人发现他们需要 mongodb 返回包含或被其他数据过滤的文档。例如，不仅要返回交易时的 customer_id，还要返回截至今天的customer_name ？很简单，只需连接到您的客户表即可。当连接速度非常慢时，您将失去大量的灵活性。
在某些时候和某些地方，mongodb 可能有意义。但就像 mysql 的领导层 20 年前告诉大家，90% 的开发人员不需要事务、视图、子选择、联合等一样，MongoDB 给人们带来了很多糟糕的建议。
—— 我使用 Multicorn FDW 迁移了一套服务于生产在线业务的 MongoDB 到 PostgreSQL。把1TB出头规模的数据，搬到使用同样硬件的 PostgreSQL 上。在这个迁移的过程中，我对 MongoDB 留下了极差的印象 —— 我花费了很多时间清洗 MongoDB 中模式错乱的垃圾数据。
在性能方面我已经忘掉了具体的数字，但还记得迁移至 PostgreSQL 后，性能有了突飞猛进的改善。之后的这么多年里，我没有再和 MongoDB 打过交道，确实也不知道 MongoDB 后面有没有什么长进。
老实说，MongoDB 能吸引到的用户，也只有同样的烂产品 MySQL 的用户了。
- MongoDB 在正确性上比 MySQL 还要垃圾得多！
- MongoDB 已经开始过气，流行度趋势下跌
通常来说，讨论性能问题离不开具体的场景。但总归是有一些通用的基本操作可以
我上一次和 MongoDB 打交道是在 2016 年 —— 我使用 Multicorn FDW 迁移了一套服务于生产在线业务的 MongoDB 到 PostgreSQL。把1TB出头规模的数据，搬到使用同样硬件的 PostgreSQL 上。在迁移的过程中，我对 MongoDB 留下了极差的印象 —— 我花费了很多时间清洗模式错乱的垃圾数据；在性能方面我已经忘掉了具体的数字，但还记得迁移至 PostgreSQL 后，性能有了突飞猛进的改善。之后的这么多年里，我没有再和 MongoDB 打过交道，确实也不知道 MongoDB 后面有没有什么长进。
于是，我做了一些简单的检索与研究，结果发现了一些非常有趣且震惊的结论：
- 在关于 JSON 存储检索性能上，PG 吊打 MongoDB！
- MongoDB 在正确性上比 MySQL 还要垃圾得多！
- MongoDB 已经开始过气，流行度趋势下跌
我在 Reddit 上看到一个帖子，怒斥 MongoDB 的问题，最令我震惊的莫过于 MongoDB 还有这么一段轶事 —— 在 3.2 的时候，拿着嵌入的 PostgreSQL 作为其“分析引擎”。而且做法和我 2016 年搞数据迁移的方式如出一辙 —— 都是用 Multicorn 编写的 FDW。
更多参考阅读
《Why You Should Never Use MongoDB》
《Why you should never, ever, ever use MongoDB》
《Bye Bye MySQL & MongoDB. Guten Tag PostgreSQL》
《Postgres Outperforms MongoDB and Ushers in New Developer Reality》
《Goodbye MongoDB, Hello PostgreSQL》
《MongoDB is dead. Long live Postgresql 》
MongoDB：奇烂无比的口碑
在 Reddit，HackerNews ，与各种论坛上都有无数的讨论。Reddit 帖：《Doubt regarding PostgreSQL vs Mongodb》
MongoDB：过气的产品
MongoDB：其实我也不赚钱
MongoDB：期货死人
https://www.theregister.com/2024/08/30/mongodb_postgresql/
关于性能
Performance Benchmark: PostgreSQL vs. MongoDB @ 2020
Can PostgreSQL with its JSONB column type replace MongoDB? @ 2023-08
关于正确性
关于流行度
StackOverflow Developer Survey 2017 - 2023
DB-Engine Ranking - Trend Popularity
关于社区
JSON/JSONB, FerretDB, mongo_fdw
The Great Migration from MongoDB to PostgreSQL
关于黑历史
Doubt regarding PostgreSQL vs Mongodb
MongoDB 3.2: Now Powered by PostgreSQL
小结
Why You Should Never Use MongoDB
群友讨论的时候抛出了一个有趣的问题，研究了一下发现 MongoDB 实在是太垃圾了，无论是性能还是正确性都被PG吊打。正好最近喷云厂商太多了，应该回归一下数据库主业，清明节准备写一篇批判 MongoDB 的文章。
性能这种要看具体场景的场景。作为一个特定经验：我在 2016 年的时候用 MongoDB FDW 迁移了一套 MongoDB 到同硬件上的 PG，性能反正好了很多。但这么多年过去了，我也不知道现在 MongoDB 怎么样了。
首先，MongoDB 公司被发现在性能方面大量撒谎。
然后人们发现该产品的数据质量也很差。
然后人们发现“无模式”实际上意味着你拥有数百万个模式。
然后人们发现MongoDB的报告子系统实际上是一个嵌入式的Postgres数据库。
然后人们发现缺乏连接实际上是一个巨大的问题。而且在繁忙的 MongoDB 集群上回填旧数据可能需要数周时间。
最后人们发现，在存储 json 的一系列基准测试中，Postgres 比 MongoDB 更快。
因此，从这一点来看，MongoDB 就像 NoSQL 世界中的 MySQL：有太多谎言、太多夸张、太多坏建议。我们中的许多人都希望永远不再看到 mongodb。
学习如何有效使用文档数据库并不需要成为营销部门的鹦鹉。这意味着了解优势、劣势和设计模式：
数据质量：当 mongodb 复制不是原子的并且您可以覆盖部分记录时 - 您会怎么做？
无模式：实际上意味着“数百万个模式”——每行可能包含不同类型的不同字段。或者您很严格，坚持使用单一模式，并频繁进行模式迁移。这违背了公司的建议，违背了他们的“无模式”公关，并且在大型数据库上可能需要很长时间。
连接：是一种非常强大的适应性功能。最终，大多数人发现他们需要 mongodb 返回包含或被其他数据过滤的文档。例如，不仅要返回交易时的 customer_id，还要返回截至今天的customer_name ？很简单，只需连接到您的客户表即可。当连接速度非常慢时，您将失去大量的灵活性。
在某些时候和某些地方，mongodb 可能有意义。但就像 mysql 的领导层 20 年前告诉大家，90% 的开发人员不需要事务、视图、子选择、联合等一样，MongoDB 给人们带来了很多糟糕的建议。
另一个更近更鲜活，就在眼前的例子：The Register 的的这篇报道中。MongoDB 声称，我们击败 PostgreSQL 拿下一个300亿美元（公司）的大单。如果不仔细看原文，很难区分这个 300 亿指的是项目，还是还仅仅是这个公司的估值。
He said MongoDB had used its database service, Atlas, to win workloads off PostgreSQL in a project at Fanatics Betting & Gaming, a division of sports ecosystem company Fanatics, which is worth around $30 billion.
于是，包括 “开源中国” 的这篇翻译稿，以及一些国内搞数据库的CEO，都在这件事上翻车了，报道出极为离谱的数字出来（赢下价值300亿美元的项目，）。其实要按这种说法，苹果密集使用了 PostgreSQL 数据库，也采购 CyberTech 的PG服务，那也从来没见过 CyberTech 吹这种牛逼我们赢得了个值 3500B（公司）的订单。
我个人是看不起 MongoDB 这个数据库的，但既然人家都打上门来踢馆了，没有人说两句也不合适。因此今天就