Why choose Couch DB over Relational Database?


Why choose Couch DB over Rational Database?

Choosing a correct database is very important in software development.

The relational database maintains ACID rules. Relational model requires relational database engine to manage writes in a special way. It locks the rows and table to maintain atomicity and consistency. Protecting referential integrity across the tables and rows increase locking time. Increase locking time means higher latency and slower application. Developers face some problems with the Relational database such as:

Object Relational Impedance Mismatch: When RDBMS is being served by an application program written in an object-oriented programming language, objects or class definitions need to be mapped to database tables defined by a relational schema. Misalignment layer of application objects to tables and rows is called Impedance mismatch.

As an example, below are the schema definitions:

Below is the application code:

Class Foo
int Id;
string[] colours;

In this example, object foo contains field Id and colours (which is a bunch of strings). To store this into the database we need to create 3 tables.

  • Main object
  • Colour information
  • Relation between color and main object

These forces the developer to write a mapping layer such as Entity Framework or ado.net to translate the objects in memory and what is saved in the database.

Many of the developers use object-oriented languages in development. Objects are not rows and tables. All objects are not uniform. Mapping those objects into rows can be painful.

Couch DB is schema-less. There is no relation between a collection of objects. A developer can store any type of document. The documents can be flat and simple or as complex as the application requires.

Couch DB document for “Foo”:





Scalability Issues: Scaling out and replicating data to other servers need to increase the lock. Relational database tries to be consistent and increase the locking time and as result application gets slower.

Replication is one of the features in couch DB. Replication takes advantage of clustering to achieve scalability. We just need to mention the source and destination database. Couch Db will handle to replicate the data into a destination. This can also be achieved through a REST call. It should be a POST request to the endpoint “_replicate” with the source and destination servers specified in the body of the request.

Define table No schema
Rows and Columns Document
Dynamic Query Predefined query
Join/Relations Not required
T-SQL Map Reduce
Management Studio Futon
Constraints, Triggers, SPS Validations, show & List Functions


Couch Db stores JSON for documents, JAVASCRIPT as MAPREDUCE queries and HTTP for an API. Couch DB can be considered as a b-tree manager with an HTTP interface. It uses a data structure called a B- tree to index its documents and views. It maintains optimistic concurrency via MVCC (Multi-version concurrency control). Previous versions of a document are available till the database is compacted.

B-trees append data only to the database file that keeps the B-tree on disk and grows at the end. B-tree delivers fast searches, inserts, and deletes.

Couch DB features on the server-side document validation and on the fly document transformation. Although a document is stored in JSON, the document can be served as XML or CSV.

Architecture OF Couch DB:

The lowest tier is simple JSON based file store. The storage engine is responsible to accept the JSON documents and serialize them into the disc. Storage engine can access the JSON store. The query engine does fast access to the stored in JSON store. The query definitions are JAVASCRIPT functions stored in the database. B-tree structured index is built on every query and stored in a database. This helps the query engine to read the data fast. Replication engine provides capabilities in master-master bidirectional replication. Through Rest API we can access any of the three capabilities.





Leave a Reply

Your email address will not be published. Required fields are marked *