啊，老套的“我用了错误的产品来解决我的问题，现在我抱怨这个产品不好，因为它……

公平地说，MongoDB的公关团队尽力将其呈现为解决所有问题的方案。 > 2012年，10gen的公司战略副总裁Matt Asay曾表示：“仍会有一小部分应用不适合MongoDB...开发人员编写的大部分应用软件将适用于MongoDB和其他NoSQL技术...那些真正帮助公司创新和增加收入的功能[将使用NoSQL]。” 他指出我们正生活在后事务性未来。 https://news.ycombinator.com/item?id=15124306

问题不是MongoDB不适合某些问题。我以前用过它，它并没有造成问题。而是它适合的问题是PostgreSQL适合的问题的一个子集。 我也可以在PostgreSQL中快速原型开发。如果我想在PostgreSQL中存储无模式的JSON，我也可以轻松做到。 > 最终，我认为拥有一系列能做不同事情的工具是很好的。 最终，我认为每个工具都需要有一个专长——它擅长而其竞争工具不擅长的东西。 Mongo没有这个。

如果Mongo只是一个文档数据库，那么真的没有理由选择它而不是Elastic。Mongo的查询功能稍微好一点，但我们这里并没有进行关系代数，对吧？Elastic在几乎所有其他方面都碾压Mongo。

文章作者在此！ 文章本身并没有"抱怨产品不好"，但此线程中的其他评论确实可能暗示如此。相反，文章指出使用场景发生了变化，说明了为什么MongoDB不再适用（虽然之前适用），以及为什么选择了PostgreSQL，还讨论了迁移过程中涉及的问题和结果。 关于与云服务提供商缺乏支持和缺乏MongoDB经验的问题，这确实不是MongoDB的问题。然而，对于试图使用MongoDB作为数据库依赖项进行自托管的平台用户来说，这确实是一个问题，因此证明了选择PostgreSQL进行迁移是合理的，因为PostgreSQL更适合这个用例。 明确地说，文章并不是说MongoDB不好，也没有指责任何一方。事实上，我认为有各种各样的使用场景，…

> MongoDB是一个文档数据库。 谢谢。对Mongo和RDBMS之间问题的一个简短说明。

>作为该技术栈的一部分，我们选择了MongoDB + Mongoose ORM，因为这种组合带来的开销最小，并使我们能够快速推出高质量的功能。正如托尼·霍尔所说，“过早优化是万恶之源”，当时确实没有必要进一步优化。 看起来在他们刚开始的时候工具做得很好。Mongo非常容易快速搭建一个原型，后来他们似乎需要迁移到更稳定的系统。

抱歉，100次中有100次，“快速原型开发”意味着“我们用错误的数据库构建了这个，现在我们被卡住了”。如果在一开始就不清楚如何存储数据，那么要么是你没有很好地规划软件，要么是你实际上并不知道自己在做什么。

> 我喜欢MongoDB是因为在快速原型设计时它易于使用。 我认为这类似于人们说编写测试通过TDD能加快速度，但其他人却完全不写测试。我认为我的体会是，只要你投入其中并且熟悉这个过程，你可以以任何方式去做。 对我来说，提前定义我的模式根本不是问题。而且Postgres给了我json列的逃生舱。结合了在应用程序生命周期后期的数据有效性保证，我每次都选择Postgres。