When is it appropriate to use couchDB?

Question

I'm currently writing an app with quite a few different data persistence needs at very different layers and I keep wondering... when is it appropriate and when is it not appropriate to use couchDB to satisfy my persistence needs?

Answer 1

See:

• What are the advantages of CouchDB vs an RDBMS
• Why should I use document based database instead of relational database?
• Pros/cons of document-based databases vs. relational databases

Answer 2

After implementing two production systems on top of nonrelational db, I came to conclusion that nonrelational dbs need to step little bit closer to sql to be really "alternative" to it. I understand alternative as "you get same functionality without huge difference in quality, effort or cost."

Short answer: Not that often

Long answer. Main benefit for non relational databases are high availability, schemaless and scalability. All of of this comes with significant price. If your application needs query flexibility (and / or, sort order, ..) and doest have large data or performance requirements you're better off with traditional DB like mysql or better postgres. Main challenge with non-relational database is that if you need new way to combine data (like all posts liked by user in time order) you'll need new document to insert and view to implement the query. Couchdb is document based that is good for flexibility, as you don't need to maintain schema in the database and can just "forget" old data that is missing the new fields. Document databases do not live up to full potential with statically typed languages though as you anyway have to more or less fix the data structure in your code.

Non-relational db requires push architecture. All data for all possible queries ( even rare admin ones ) needs to pushed when you insert or update data. This costs as cpu and disk but you get fast queries. In SQL based db you can just insert the row and pay the price as slow queries. CouchDB builds indexes on the first query, some other databases on insert (MongoDB, Google App Engine)

Couchdb queries are defined as javascript views that are powerful but pretty difficult to write, maintain and debug. View change means that couchdb needs to reindex all documents that is really slow if you have million or more documents. The error messages from couchdb can not be deciphered by usual admin.

Couchdb maintanance needs some manual effort to compact datafiles and indexes, new versions have automatic compaction though but using it requires some care. Compactions need to be scheduled off-peaks etc.. This can scripted pretty easily though. Db dump, backup and such tools are still pretty infant.

In short, it's not worth the effort if you're not going to need the performance or scalability of the couchdb. Personally I think its possible to "emulate" most non relational db performance benefits with sql db, redis and memcache stack. At least as long as the there is not too much data.