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

1. No Schema. Less time designing the database.
2. Sync ready. Build offline-first apps easily.
3. Map/Reduce way of building an index is helpful in some situations.
4. Create a fully working RESTful API in no time.
5. Version 2.0 has much more features.

The bad

1. Libraries that can communicate with CouchDB are still lacking.
2. Steep learning curve for people with SQL background.
3. Version 1.0 can’t query documents without creating an index (Solved in Version 2.0)
4. Your application layer will be responsible of all the hassles that SQL can take care of easily

The ugly

1. 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.
2. 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.