A little about CouchDB

I've read CouchDB Guide for the second time recently. Very interesting book, it's interesting to understand how CouchDB works internally, one of those rare books that creates a mind shift and expand it to the new territory. It's definitely worth the time spent even if I never will be using CouchDB.

So, what's good about CouchDB:

  • Reliable, can accept thousands of connections and behave elastically and predictably under high load (MongoDB is also pretty fast).
  • Has ability to efficiently (without blocking and copying) make snapshot of database state using MVCC (MongoDB can't to that).
  • High availability - thanks to MVCC it's never blocked (MongoDB block on write, although usually it's not a problem, unless you have write-heavy application).
  • Incremental Map/Reduce (MongoDB can do something similar).
  • Incremental, non-blocking, consistent replication (MongoDB also can do it).
  • Has notifications / change-log (MongoDB doesn't have it).
  • Has versioning, although pretty basic (MongoDB doesn't have it).

Now, about disadvantages:

  • Sadly, CouchDB is harder to use than MongoDB or RDBMS. Definitely it's not the easiest way to create a web application. If you ever used Map/Reduce you probably know that with all its power in performance it has a drawback - it's hard to use, much harder than usual ways. In CouchDB the Map/Reduce is the only way to query (MongoDB queries even simpler than RDBMS).
  • No in-place update, it's impossible to update only one field in the document, only the document as a whole. Actually, it's not the drawback but consequence of immutability and MVCC design, but sometimes this feature may be very useful (MongoDB has this feature).
  • No support for Map/Reduce chaining, so, only basic queries and aggregations are possible. Usually you won't frequently need advanced aggregations, so it's not a big problem, but it limits usage of CouchDB as an analytical engine (MongoDB has this feature).
  • No support for sharding / scale out of the box. There are some 3rd party libraries, but with very basic functionality (MongoDB has support for it out of the box).

Popularity

MongoDB is red, CouchDB blue.

My personal, subjective complains:

  • Messy documentation. The concept of MVCC, B-trees and Map/Reduce is complex enough by itself. But as if it's not yet enough - for some unknown reason half the documentation devoted to web-application features of CouchDB (which is totally unnecessary and uninterested for 99% of readers). What's worse these parts are mixed up so it's hard to ignore all this annoying web app CouchDB stuff.
  • Poor project management. Project hosted on GitHub but there's no GitHub tickets. You has to go to Apache JIRA, register there, and only then can submit a bug report. Majority of users will never bother to do all this stuff to submit a found bug.
  • Poor user support. There's no official forum or Q&A board, there's old and extremely inconvenient to use apache mail list, and the only emotion you feel when seeing it - click the close button.
  • There are many words like "high-availability", "scalability", "high-load" and so on - and you are eager to see all this cool stuff in action - and then - surprise out of the box CouchDB can do none of it. There are some 3rd-party tools that can do limited things, and that all. Why then make loud claims and promises about scalability in the first place?

Resume

CouchDB is specialised database (not universal as it's usually referred to). It has some unique features that stand it apart from most databases and make it a good fit form some use cases, but it's not the good fit for a general use case. Special tools should be used in special situations, not on the day to day practice.

And I believe it's the biggest difference from MongoDB. MongoDB is simple and has all the features that usually needed by common web application. It doesn't have some features of CouchDB, but those features are usually not needed in common cases.