NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



8 Reasons You Should Like CouchDB… and not only

While this is not the ☞ original title, I’d say it would summarize pretty well Jilles Van Gurp’s post about the set of features he liked most in CouchDB:

Document oriented and schema less storage

That’s definitely not unique. Here on MyNoSQL, we are aware of at least 4 document databases: CouchDB, MongoDB, Riak and Terrastore.

Conflict resolution

MongoDB encourages a master-slave setup so it will not have to deal with conflict resolution. Terrastore doesn’t have to address this either as the value of a key lives on a specific node and updates will be applied in their chronological order. Riak uses vector clocks for conflict resolution.

Robust incremental replication

Replication is supported by both Riak and MongoDB. Terrastore, being built on top of Terracotta, uses a different strategy:

Terracotta replication is not full, nor geared toward all nodes, but only those actually requiring the replicated data. This is more and more optimized in Terrastore, where, thanks to consistent hashing and partitioning, data is not duplicated at all. Terrastore also guarantees that data will never be duplicated among nodes, unless new nodes are joining or older nodes are leaving, thus requiring data redistribution.

You can read more about Terrastore approach on Terrastore: a consistent, partitioned and elastic document database.

I leave it up to the readers to comment based on their experience how robust replication is in each of the MongoDB, Riak and Terrastore case.

Fault tolerant

The explanation in the original article is more about durability than fault tolerance. In that regards, as far as I know only MongoDB is not really durable.

On Riak case, each write operation can specify the number of virtual nodes involved in the operation and also the number of successful durably writes.

Terrastore is durably storing its data on master whose availability can be enhanced by putting it in active/passive mode (simply put there can be passive masters that would take on the tasks once the initial master has failed).

I should probably mention that in terms of the fault tolerance definition, both Riak and Terrastore are fault tolerant.


Both Riak and Terrastore are HTTP friendly.

I left at the end the three reasons that are either more specific to CouchDB implementation or are debatable.

  • cleanup by replicating

This sounds more like something specific to CouchDB append only approach.

  • incremental map reduce on read

I’m not sure I understand the benefits of this.

  • it’s fast

As always, this sort of arguments are highly debatable and it always a good idea to use very well crafted benchmarks that fit your app scenarios.

In conclusion I’d say we ended up with 5 reasons you should like CouchDB and Riak and Terrastore. And I bet a change in the requirements (see as an example: On why I think these pro MongoDB arguments are not unique) would result in any other combinations of these four NoSQL solutions.

Special thanks to Sergio Bossa for clarifying some aspects related to Terrastore.