In short, Use CouchDB if you are 100% sure you won’t need any (complex) joins.
This post won’t go through any theoretical differences or benchmark scores, only different use cases that I find really important to consider before using CouchDB.
CouchDB is the dream DBMS in some situations where you need a schema-less database, just push anything into the database, index it and voila you have a fully operational RESTful API.
CouchDB can be deceptively simple.
What I truly like about CouchDB is the idea of having anything of any form in a single database that can easily sync. CouchDB uses master-master replication. Any node can sync to any node. You can even create a node withing your offline app using PouchDB. CouchDB really made my life really easy in some projects, however, it can REALLY make your life a disaster in other situations.
The good
- No Schema. Less time designing the database.
- Sync ready. Build offline-first apps easily.
- Map/Reduce way of building an index is helpful in some situations.
- Create a fully working RESTful API in no time.
- Version 2.0 has much more features.
The bad
- Libraries that can communicate with CouchDB are still lacking.
- Steep learning curve for people with SQL background.
- Version 1.0 can’t query documents without creating an index (Solved in Version 2.0)
- Your application layer will be responsible of all the hassles that SQL can take care of easily
The ugly
- You can’t do any joins, you can create what can be called a direct join by emitting parent document as well as _ids of the secondary (Child) entities and Couch will create the link for you. Other than that you are on your own.
- CouchDB can fool you in a lot of situations to believe it would be the best DBMS for your new system, but you must think twice. Some not-yet-required features may force you to convert your project to SQL in later point which will cause you enormous losses in time & money.
For these reasons, I’ve reached a conclusion to not use CouchDB if the required system can be modeled to a SQL schema. As long as SQL can be used, It should be used.
Using CouchDB as DBMS is really enjoyable experience and if it matches your system requirements you will deliver your system much faster than if you use SQL, however, if at any point you need a complex join, you will be left with one of two options : Implementing the join in your application layer or abandoning CouchDB in favor of SQL.
PSM™, TiTrias Founder and CEO, white hat hacker acknowledged by Microsoft, Apple, Redhat & AT&T. Publisher of GANKIN in SN Applied Sciences. Drafter at historydraft.com.
I hear you – completely! However, it still begs the question, “How do you create an offline first app using a SQL DB??
Sometimes I curse Couch/Pouch DB for daggling the ‘golden goose’ carrot in front of our eyes but leaving us with no real viable solution for complex ‘real world’ web apps.
You are absolutely correct, we are still using Couch/Pouch is multiple projects, for example https://www.titrias.com/how-to-pouchdb-couchdb-database-per-user-made-simple/ and it’s doing amazing job!
You should add “lack of transactions” to your “bad” list. There is no way to perform multiple actions across the CouchDB API and have a transaction abort if something goes wrong. Guaranteeing that data consistent under these conditions is near on impossible.
“Lack of transactions” is one of the hassles your application layer will be responsible for, I will add it explicitly.