使用MongoDB，您可以 * 存储 * JSON对象，并以完整的格式检索它们，因此您实际上不需要ORM层，而且来回转换数据花费的CPU时间也更少。MongoDB背后的开发人员还将数据库的横向扩展作为更高的优先级，并允许您运行任意Javascript代码来预处理数据库端的数据（允许map-reduce样式的数据过滤）。
但你为这些收获失去了一些：你不能连接记录。实际上，你存储的JSON结构只能通过SQL中的连接来完成，但是在MongoDB中，你只有一个数据结构，而在SQL中，你可以用不同的查询方式，以不同的方式更容易地表示你的数据，所以如果你需要对你的数据库做很多分析，MongoDB会让这变得更难。
在我看来，MongoDB中的查询语言比SQL的查询语言“粗糙，”部分原因是它不太熟悉，部分原因是查询特性“感觉”是随意放在一起的，部分原因是为了使它成为有效的JSON，部分原因是确实有几种方法可以做同样的事情，和子对象类型比SQL简单的基于行的设计增加了复杂性，因此语法必须能够处理对包含 * 一些 * 您定义的值、包含 * 所有 * 您定义的值、* 仅包含 * 您定义的值以及 * 不包含 * 您定义的值的数组的查询。同样的区别也适用于对象键和它们的值，这使得查询语法更难掌握。（虽然我可以看到对边缘情况的需要，但是$where查询参数，它接受在每条数据记录上运行的javascript函数，并返回一个布尔值，是一首Siren歌曲，因为你可以很容易地定义你想返回或不返回什么对象，但是它必须在数据库中的 * 每个 * 记录上运行，不能使用索引。）
因此，这取决于您想做什么，但既然您说是针对Google Docs克隆，那么您 * 可能 * 不关心任何表示 *，而 * 关心文档表示本身，并且您 * 可能 * 只会基于文档ID、文档名称或所有者的ID/名称进行查询，查询过程中没有太复杂的内容。
然后，我会说，能够将用户正在编辑的文档的JSON表示形式放入数据库中，并让它自动为这些重要字段建立索引，这是值得学习新数据库的代价。

我也在为这个选择而挣扎，因为MongoDB的任务不是为它而设计的，所以我的2分钱是：
1.正如David所说，在MongoDB中存储和检索层次对象（文档可能就是这样）更容易，但如果要存储大于16 Mb的文档，则会变得更复杂-- MongoDB的答案是GridFS。
1.在文件夹、组中组织文档，跟踪哪个用户拥有哪些文档，以及他/她向谁提供了对这些文档的访问权限，这些都可以通过MySQL轻松实现--您可以利用强大的SQL查询（带连接等），内置EXPLAIN优化、触发器、函数、存储过程等。MongoDB远远不能与之相提并论。
那么，是什么阻止了您同时使用MySQL来组织文档和MongoDB来存储一个由id标识的文档集合（或多个集合-每个文档类型一个集合）呢？在我看来，这是最好的选择，在一个应用程序中使用两个数据库并不是问题，真的。
MySQL将存储用户、组、文件夹、权限--任何你喜欢的东西--对于每个文档，它将存储对集合的引用和文档ID（MongoDB有一个特殊的格式-- DBRefs）。MongoDB将文档本身存储在集合中，如果它们都小于16 MB，或者将文档的预览和元数据存储在集合中，将整个文档存储在GridFS中。

大卫给出了一个很好的答案，还有几点需要补充。

1. MongoDB的灵活特性允许轻松敏捷/迭代开发。
2. MongoDB和node.js一样，本质上是异步的，在异步环境中工作得很好。
3. Mongoose是一个很好的ODM（对象文档Map器），它使得使用MongoDB和Node.js的工作感觉非常自然。
   对于Google Doc之类的功能，MongoDB提供的灵活性和非常丰富的数据结构感觉更适合。
   你可以通过搜索mongoose，node和MongoDB找到一些很好的示例帖子。
   这里有一个同样使用backbone.js的，看起来不错的http://mattkopala.com/blog/2012/02/12/getting-started-with-nodejs/