| I think it was Rich Hickey that said the document database is the worst of them all, because you are now married to that structure. Having used Couchdb in production for two years, I have to agree with his analysis, and offer my own opinion that Couchdb is highly overrated. Not because it is not a good implementation of a document style database, but because the document store itself is not a good match for most use cases. If the only requirement is a replicated JSON document store, it may work OK for you. But so would Riak, Postgres and some others. If you need to update the data in those documents or ever need to query the data in ways you did not initially envision, you will quickly find yourself missing features which even traditional SQL databases are very good at. Development is slower. Writing map/reduce for queries seems particularly cumbersome, particularly if you prefer not to use Javascript. And you have to plug them into a textarea in a webpage interface, or manually put them into Couchdb over http using curl or some library that abstracts this away. Either way it is a degree of separation that makes the data feel more out of reach than through a console interface like psql or mysql. Consider the scenario where you want to update the value in an attribute on several thousand, or even just several documents that match some criteria. In SQL, you would simply jump in the console and in a few seconds or minutes complete that as a transaction with something like: > update table set col=val where criteria. There is no such feature in Couchdb. You will need to write code to filter and fetch each matching document, manipulate it as needed, then write the entire thing back. All to update a few bits that hopefully were not nested too deep as that really increases the complexity of the code you will need to write. As memracom stated, the replication is not perfect. My experience even on a low latency network is the only safe way to ensure a client can immediately read back what they just wrote is to pass them through the likes of haproxy and use a sticky session. Otherwise you have a good probability of getting a 404 after a POST (create) or stale data after a PUT (update). So for what it is worth, here is my advice on choosing a database from an ease of development standpoint: 1) has as many features as you can, even if you don't need them initially
2) has top notch libraries for your language / framework
3) has relation awareness - do not denormalize unless you must
4) supports consistency
5) supports in place updates - easily filter and change values (doesn't apply to Datomic)
6) has tools to make schema changes / reshaping data is easy, and can be done online Maybe 2 years ago Couchdb was a great solution. But with memory and ssd storage being so cheap and so much innovation with traditional and NoSQL DBs, I don't foresee myself deploying Couchdb again. If I did need a place to dump some semi-structured data, I find Amazon's hosted offerings more attractive. |
However I dont agree that many (or any) other things are suitable alternatives for replicatable json stores, in this case where replication means peer to peer stores that can operate offline for any period of time.
My particular interest these days is building web applications that work well offline, its why I build PouchDB, while its entirely possible to build a home made sync solution on top of your favourite database, its an extremely hard problem and something I see app after app try and fail constantly.
If I didnt need the ability sync data that would work offline, I wouldnt use CouchDB (pouchdb/cloudant etc), but since that is what I am interested in, right now I think its pretty much the only choice.