我相信你可以用Mongo(更熟悉它)，你也可以用沙发。

两者都是面向文档的(基于json)，因此在文档中没有“列”，而是字段——但它们可以是完全动态的。

它们都能做到，你可能需要考虑其他可以使用的因素:你关心的其他功能，受欢迎程度等等。谷歌的见解和indeed.com的招聘信息是衡量受欢迎程度的方法。

你可以试试，我想你应该能在5分钟内让mongo运行起来。

C, A和P(一致性，可用性和分区容忍度)，哪两个对你更重要?快速参考，NoSQL系统的视觉指南

MongodB:一致性和分区容忍 CouchDB:可用性和分区容忍

一篇博客文章，Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j比较了每个NoSQL数据库的“最佳使用”场景。引用链接，

MongoDB:如果你需要动态查询。如果您更喜欢定义索引，而不是映射/减少函数。如果您需要在大DB上有良好的性能。如果您想要CouchDB，但数据更改太多，会填满磁盘。 CouchDB:用于积累偶尔更改的数据，并在这些数据上运行预定义的查询。版本控制很重要的地方。

Riyad Kalla最近(2012年2月)进行了一项更全面的比较，

MongoDB:主从复制 CouchDB:主-主复制

一个尝试过这两种方法的人的博客(2011年10月)评论说，CouchDB的分页功能并没有那么有用。

Kristina Chodorow (MongoDB背后团队的一部分)编写的日期为2009年6月的基准测试，

我会选择MongoDB。

注意MongoDB中稀疏唯一索引的一个问题。我已经击中它，它是非常麻烦的工作。

问题是这样的——你有一个字段，它是唯一的，如果存在，你希望找到所有的对象，该字段不存在。在Mongo中实现稀疏唯一索引的方式是，缺少该字段的对象根本不在索引中-它们不能通过对该字段的查询检索- {$exists: false}不起作用。

我提出的唯一解决办法是有一个特殊的null值族，其中一个空值被转换为连接到uuid的特殊前缀(如null:)。这是一个真正令人头痛的问题，因为在写入/查询/读取时，必须注意从空值转换到空值。一个大麻烦。

我从未在MongoDB中使用过服务器端javascript执行(无论如何都不建议)，当只有一个MongoDB节点时，他们的map/reduce性能非常糟糕。由于所有这些原因，我现在正在考虑使用CouchDB，也许它更适合我的特定场景。

顺便说一句，如果有人知道描述稀疏唯一索引问题的Mongo问题的链接-请分享。

我总结了在那篇文章中找到的答案:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

MongoDB:更好的查询，数据存储在BSON(更快的访问)，更好的数据一致性，多个集合

CouchDB:更好的复制，主到主复制和冲突解决，JSON格式的数据存储(人类可读，通过REST服务更好的访问)，通过map-reduce进行查询。

总之，MongoDB更快，CouchDB更安全。

还:http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

所有这些答案都把故事复杂化了。

如果您计划使用移动组件，或者需要桌面用户离线工作，然后将他们的工作同步到服务器，那么您就需要CouchDB。 如果你的代码只在服务器上运行，那么就使用MongoDB

就是这样。除非你需要CouchDB复制到移动和桌面设备的能力，否则MongoDB目前在性能、社区和工具方面都有优势。

非常老的问题，但它在谷歌上面，我不太喜欢我看到的答案，所以这是我自己的答案。

Couchdb的功能远不止开发CouchApps。大多数人在经典的三层web架构中使用CouchDb。

在实践中，对于大多数人来说，决定因素是MongoDb允许使用类似SQL的语法进行自组织查询，而CouchDb不允许(你必须创建映射/缩减视图，这让一些人望而却步，尽管创建这些视图对快速应用程序开发是友好的——它们与存储过程无关)。

为了解决在公认的答案中提出的问题:CouchDb有一个很棒的版本控制系统，但这并不意味着它只适合(或更适合)版本控制很重要的地方。此外，couchdb由于其仅追加的特性(写入操作立即返回，同时保证不会丢失任何数据)，因此是重写友好的。

没有人提到的一个非常重要的事实是，CouchDb依赖于b-树索引。这意味着无论你有1个“行”还是200亿，查询时间将始终保持在10ms以下。这是一个游戏规则改变者，它使CouchDb成为一个低延迟和读取友好的数据库，这真的不应该被忽视。

公平而详尽地说，MongoDb相对于CouchDb的优势在于工具和营销。他们为所有主要语言和平台提供了一流的公民工具，使入职变得很容易，加上他们的特别查询，使从SQL的过渡更加容易。

CouchDb没有这种级别的工具——尽管现在有很多可用的库——但CouchDb是作为HTTP API公开的，因此很容易用您喜欢的语言创建一个包装器来与它对话。我个人喜欢这种方法，因为它避免了膨胀，允许你只拿你想要的东西(接口隔离原则)。

所以我想说，使用一种或另一种很大程度上是对他们的范式的舒适和偏好的问题。CouchDb方法对于某些人来说“只是适合”，但是如果在了解了数据库特性(在详尽的官方指南中)之后，您还没有“太好了”的时刻，那么您可能应该继续前进。

如果您只是想“用正确的工具做正确的工作”，我不建议使用CouchDb。因为你会发现你不能这样使用它，最后你会很生气，并写博客文章，比如“CouchDb中的连接在哪里?”和“事务管理在哪里?”实际上，Couchdb是非常透明的，但与此同时，它需要进行范式转换，并改变处理问题的方式，这样才能真正发挥作用(并真正发挥作用)。

但一旦你这样做了，就真的会有回报。就我个人而言，我需要非常有力的理由或一个项目的主要交易破坏者来选择另一个数据库，但到目前为止，我还没有遇到任何。

2022年12月更新: 由于这篇文章的浏览量仍然很大，我觉得有必要告诉人们，我最近已经开始使用MongoDB作为我的日常驱动程序，同时保留CouchDB作为我的工具带，用于特殊情况，在这种情况下，数据库更有意义(即不需要视图的情况)。做出这个选择的原因有很多，其中最重要的是:

Performance: While precomputed indexes are a powerful asset, the main limitation of CouchDB is its QueryServer architecture. Every time a document is updated, it has to be serialized and processed by every view (even though this happens in a deferred manner, namely when the view is accessed). But more importantly, every time a view is updated (for example to add filtering logic for a new field added as part of the implementation of a new feature), ALL documents of the database must be sent to the view. This becomes a big deal when you have millions of documents in the database. You start worrying about the impact of updating your views and it becomes a distraction. Should you decide to create one database per data type to bypass this limitation, you'd then lose the ability to map/reduce across all your documents since views are scoped per database. MongoDB avoids this by segmenting documents into collections (ie. data types) so that when an index is updated only a subset of the data of the database is impacted. Moreover, MongoDB uses a binary format making these operations way more performant (while CouchDB uses JSON sent to the view server in plain text). This point may not be important if you do not design products needing to operate at large scale (hundreds of thousands of daily users or more). the tooling available with MongoDB is comprehensive and mature, whether we are talking about the drivers officially supported for various programming languages, or integration with IDEs. Advanced querying: A wide range of data types and advanced query capabilities are available out of the box (geo types, GridFS allowing one to store files of arbitrary size directly in the DB etc...). Having easy access to powerful query aggregation capabilities made me realize how much CouchDB had been inhibiting my productivity. Seamless support for resharding: resharding is easy with MongoDB, while it is a dangerous operation involving moving files by hands with CouchDB. Many other small items that improve quality of life and really add up.

I have been a big CouchDB fan but I have to admit that moving to MongoDB as a daily driver felt a lot like moving back to civilization in terms of productivity and quality of life improvement. Now I only consider CouchDB for key-value store scenarios (in which no map-reduce views are required and all that is needed is getting a document by key - CouchDB shines quite a lot for this), and advanced situations in which having per-user like databases is needed (for example to support advanced synchronization between devices).

MongoDB的唯一缺点是它会消耗大量内存，以至于我无法在低规格的开发机器上安装它(相比之下，couchdb在启动时就启动了，而且几乎不消耗任何资源)。然而，考虑到节省的时间和提供的功能，我觉得这是值得的。

作为一个长期的CouchDB用户，我在MongoDB中看到的价值与其他推广MongoDB的答案中突出显示的项目有很大的不同，所以我觉得提供这个更新对我来说很重要(老实说，当我想起这篇文章时，也是出于智力上的考虑)。与我一直使用的SQL产品和orm相比，CouchDB大大提高了我的工作效率，当时有很多关于MongoDB可靠性的可怕故事在流传。

然而，到目前为止，我所担心的一些问题(这可能被互联网人赋予了不成比例的重要性——它们基本上都归结为默认，其可靠性权衡可能会让新用户在许多情况下感到惊讶)不再成立。

在这一点上，作为一个长期的CouchDB用户，我可以很好地比较这两种产品，我会向那些需要高效和可扩展的web应用软件开发经验的人推荐MongoDB，并建议只根据特定需求选择CouchDB。

CouchDB had momentum back in the days which probably influenced my perception, but development has stalled, no meaningful features have been introduced for a long-time, otherwise it would probably have caught up with MongoDB in terms of quality of life. I see two possible reasons for this: the way a now aborted rewrite of CouchDB has diverted resources for a long-time, and maybe early architectural decisions (such as the Query Server architecture) that may very well have restricted its future from the start. None of these aspects seem to be the priority of the core team.

I do not totally regret choosing CouchDB because it has been massively helpful and the mindset it has taught me is extremely helpful to allow me to write performant code in MongoDB (writing performant code in MongoDB is a breeze compared to the discipline one has to observe to solve business problems using CouchDB). However if I had to do it again today, I would have transitioned to MongoDB as my daily driver MUCH sooner. I'm usually quite good at picking the winning horse when technologies popup, but this time it seems I haven't played the game that well. Hope this helps.

自己问这个问题?你将决定你的DB选择。

Do you need master-master? Then CouchDB. Mainly CouchDB supports master-master replication which anticipates nodes being disconnected for long periods of time. MongoDB would not do well in that environment. Do you need MAXIMUM R/W throughput? Then MongoDB Do you need ultimate single-server durability because you are only going to have a single DB server? Then CouchDB. Are you storing a MASSIVE data set that needs sharding while maintaining insane throughput? Then MongoDB. Do you need strong consistency of data? Then MongoDB. Do you need high availability of database? Then CouchDB. Are you hoping multi databases and multi tables/ collections? Then MongoDB You have a mobile app offline users and want to sync their activity data to a server? Then you need CouchDB. Do you need large variety of querying engine? Then MongoDB Do you need large community to be using DB? Then MongoDB