2个观点为什么PostgreSQL 和 DocumentDB 有值得 MongoDB学习的地方（翻译）-优快云博客

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

原文：

https://www.infoworld.com/article/4048740/why-documentdb-can-be-a-win-for-mongodb.html

尽管MongoDB最近一个季度的表现堪称出色（确实非常出色），但更值得关注的或许是某些人认为可能损害其未来季度业绩的因素：由Linux基金会托管的DocumentDB。这个被称为“完全开源、兼容MongoDB的文档数据库”的项目，理论上可能分流MongoDB的开发者。但故事不止于此。DocumentDB还为MongoDB提供了一个机会——借助行业资助的努力推广其数据建模方法，而这是它成功应对日益流行的Postgres所必需的。

正如MongoDB资深员工马特·基普（Mat Keep）所言：“这对MongoDB而言……是一个将自身API确立为……NoSQL标准的绝佳机会。”

MongoDB“单打独斗”的策略在Postgres的社区势能面前逐渐失效，且尚未在SQL标准领域占据一席之地。若想在与开放、可移植默认方案的竞争中胜出，同时大幅扩展整体可寻址市场，MongoDB需要拥有自己的开放、可移植默认方案。DocumentDB应运而生。

DocumentDB与“引力” Linux基金会的DocumentDB是微软今年早些时候发起、现已捐赠给LF的新开源项目。需注意的是，它与亚马逊的DocumentDB服务无关（尽管令人困惑的是，亚马逊团队已表态支持这一相关但独立的项目）。其目标是提供一个宽松许可、兼容MongoDB、基于Postgres的文档数据库，并计划围绕文档API和行为建立开放标准。AWS已加入项目技术指导委员会，谷歌公开表示支持，项目章程将一致性（conformance）和跨供应商可移植性列为核心目标。正如Linux基金会执行主任吉姆·泽姆林（Jim Zemlin）所言，最终目标是“像SQL为关系型数据库所做的那样，为基于文档的应用程序建立开放标准”。这是一个大框架，而非小分叉。但它会是个大问题吗？ MongoDB的挑战：“引力”而非特定云厂商 Postgres已成为开发者的“安全”默认选择。它受益于数十年的标准化（SQL/ISO 9075）、一致性预期，以及将其视为“基础配置”的庞大工具链。标准降低了风险和转换成本；生态系统围绕标准生长。若MongoDB想阻止Postgres吞噬更多潜在增量市场，它需要降低转向“MongoDB方式”的成本——不仅是转向MongoDB的云服务（Atlas）。

这并非争议话题——历史早已证明。若你在80、90年代开发应用，SQL作为ANSI和ISO标准的崛起对开发者和企业产生了三方面关键影响：技能与代码的可移植性：掌握SELECT、JOIN和事务不是押注于某家厂商，而是押注于职业生涯。开发者无需重新学习基础即可在厂商间迁移；企业可以招聘“懂SQL”的人才，而非“熟悉厂商X专用语言”的人。

跨厂商的可预测性：标准未消除差异，但创造了足够共识，让架构师能规划低锁定风险的长期系统。工具因“核心”可靠而爆发式增长。

差异化卓越的空间：厂商竞争的焦点是性能、运维、安全、生态和管理工具——而非“GROUP BY是否存在”。甲骨文并未对抗这股浪潮；它引领并乘势而起（注：作者任职于甲骨文，且曾两次任职于MongoDB）。甲骨文推出了首款商用SQL关系型数据库管理系统（RDBMS），随后通过跨平台可移植性、性能和运维能力超越对手，满足企业需求。标准扩展了市场；作为SQL标准的代表，甲骨文凭借最优质的管理体验和周边生态占据了巨大份额。这对MongoDB有何启示？助人即助己标准降低了所有人的门槛。若你的策略依赖专有控制，这或许令人不适。但恰恰是推动标准，才能培育你最有望胜出的领域。MongoDB已在研发上投入数亿美元，而Postgres获得的行业集体投资是其数倍。更强劲的市场级文档标准将缓解这种投资失衡，做大整个文档数据库市场蛋糕，而MongoDB因其品牌和产品的投入，恰好能分得其中一大块。

更直白地说：控制是有限的；影响力是复利增长的。SQL没有摧毁甲骨文或SQL Server——反而让它们更壮大。Kubernetes没有让云服务同质化——反而将竞争导向管理体验、安全和可靠性。MongoDB同样可以把握这一动态。

当然，受益的不止MongoDB一家，但这是优势而非缺陷。AWS、谷歌等企业正积极投入DocumentDB，因为它们也希望从中获益（并将为此投入相应资源）。我的雇主甲骨文虽未宣布支持该标准，但同样会受益。甲骨文数据库23ai推出了JSON关系双重性（JSON Relational Duality），允许开发者以可更新的JSON文档形式呈现和修改同一底层关系数据（无需数据冗余），并通过MongoDB兼容API、REST和SQL访问。这非常酷。标准往往能实现这种“兼得”，而生态系统会放大这种效应。若中立的文档标准明确了API行为和语义，厂商即可在API之下创新数据存储与优化方式——这正是甲骨文通过统一文档与关系模型于单一引擎所做的事。

换言之，当“表面层”（开发者体验与API）可预测时，买家会选择运维卓越、可扩展、治理完善且具备相邻能力（分析、AI、安全）的方案。这正是MongoDB十年来在Atlas上持续投入的方向。标准不会抹除这些优势；反而会放大它们。另一种选择是用许可协议继续对抗“引力”。这条路已被证明会缩小分发范围和用户好感。DB-Engines趋势显示，自MongoDB从开源转向服务器端公共许可协议（SSPL）以来，Postgres持续攀升，而MongoDB的增长相对平缓——尽管MongoDB公司的商业化表现极为出色。你可能在收入战获胜，却输掉平台战。既吃标准蛋糕，又全享其味MongoDB无需放弃路线图控制权即可收获标准化的益处。实际上，该公司可以用少量控制权换取巨大影响力。

在关键处定义兼容性：聚焦规范与测试。MongoDB内部已有深度的一致性测试套件。将其中一部分作为中立的、聚焦核心CRUD、查询语义、索引行为和错误处理的合规性测试工具包捐赠，既能将MongoDB定位为标准代表，又为商业差异化（如高级聚合、Atlas搜索、在线归档、向量功能）保留空间。分级一致性计划（核心、扩展、企业级）可效仿云原生计算基金会（CNCF）或SQL标准的实践。主导驱动程序生态。Linux基金会项目目标是“100%兼容MongoDB驱动程序”。MongoDB可通过明确驱动预期（线协议细节、重试语义、变更流）并联合编写中立驱动合规文档来助力。这既保护开发者免受细微不兼容困扰，又强化MongoDB作为“MongoDB方式”参考实现的角色。

倡导迁移友好的基线。在市场需要稳定性的领域——ID、BSON类型、索引行为、错误代码——MongoDB可优先考虑可预测性而非“巧妙设计”。标准可定义这些而不冻结MongoDB的创新。ANSI SQL的历史颇具启发：标准化80%，创新20%，再将最佳创意反哺标准或作为增值扩展保留。善用中立性。开发者信任中立的治理模式。Linux基金会通过技术指导委员会和章程鼓励多厂商协作与透明决策。MongoDB应积极参与，贡献界定清晰的成果（测试与规范），并协助塑造平衡实用性与MongoDB模型忠实度的兼容性“配置文件”。再次强调，影响力大于控制权。

在客户感知处差异化。标准做大市场，体验赢得订单。持续加码Atlas的运维卓越、安全、AI集成、数据分层、多区域韧性，以及围绕文档模型的“全应用”工具链。目标不是阻止他人“说MongoDB语言”——而是确保当他们这样做时，Atlas仍体验更优。

若DocumentDB成功建立可信、中立的文档数据库标准，将发生两件事：其一，以文档为中心的设计市场将扩大。架构师获得渴求的可预测性，团队得到需要的技能可移植性。这将吸引原本可能默认选择某种SQL/关系型方案的工作负载。其二，MongoDB的比较优势将复利增长。随着尝试文档建模的摩擦降低，更多团队将评估MongoDB Atlas。

MongoDB已花费多年确保自己捕获现有文档数据库市场的大部分份额。DocumentDB的时刻，是它做大这块蛋糕的机会。拥抱标准。参与编写。引领方向。自信地在企业可规模化交付的体验上展开竞争。

若MongoDB不参与定义开放文档标准，Postgres将持续将开发者锁定在SQL/关系型阵营。而这是MongoDB唯一承受不起的结局。

2个观点为什么PostgreSQL 和 DocumentDB 有值得 MongoDB学习的地方 （翻译）

2个观点为什么PostgreSQL 和 DocumentDB 有值得 MongoDB学习的地方（翻译）