Both Couchbase and MongoDB are document store NOSQL databases, providing some measure of ACID properties and a query language. As NOSQL databases, they primarily target applications that store JSON data. Nosql technology supports a very flexible programming model because a JSON document can easily capture the complex data models of modern applications such as IOT data management and OLTP apps.
Mongo has been around since 2009. Couchbase was first released in 2010. So they are roughly the same age. They do the same thing: They are NoSQL databases to store documents. But when comparing the two technologies, Couchbase comes out as more mature incarnation of the same idea.
Couchbase offers a number of improvements over Mongo features with regards to topology, performance, and manageability.
Key-Value Database
Couchbase can be thought of as a key-value database, kind of like a giant hash table, but with database features, such as ACID transactions. When storing documents in Couchbase, one first needs to create a data bucket. That is like creating a hash table. Then each document can be stored with a key and subsequently can be retrieved by that key. Retrieval by key is very efficient; again the hash table analogy holds.
Master-slave vs all nodes are equal
In a Couchbase database, all nodes are equal. This means you can connect to any node in a cluster, and that node will manage the communication with the rest of the cluster. Mongo has a rigid master-and-servant architecture, which requires more forethought when setting it up. With Couchbase, you can connect to any node and it will act as sort of master for your connection.
Workload isolation
In order to scale a database, it’s often desirable to isolate workloads so that different performance tuning measures can be applied to certain kinds of work loads. For instance you might have a real time data feed which has to run very fast and you might have a sort of queue processing adapter, that simply has to store documents with eventual consistency. These have very different performance requirements. Couchbase was designed to offer workload isolation from the ground up from the ground up
Scaling as a separate concern
When designing a Mongo database, the design has to incorporate concepts that are related to scaling, rather than application requirements. For example, rigid sharding is put in place to improve performance. But ideally, we don’t want to affect the database’s logical structure in order to scale performance: We want performance to be a separate concern, entirely independent of how the application thinks of the database. One reason for this is because we may want to change the performance tuning with changing the database structure, so that the application would not be affected. Think write once, run everywhere. We want to be able to design a database once, and then deploy it on different architectures with different performance characteristics.
Caching deficiencies
With Mongo caching was an afterthought, whereas with Couchbase, it is a core part of the codebase, which means it is well integrated and so straightforward to use.
Routing deficiencies
Interacting with Mongo often implies complicated interactions through suboptimal routing paths between nodes. In Couchbase, these routing deficiencies have been reduced.
Patchwork of features
In general, Mongo has developed over time as features were cumulatively added in a way that did not allow them to be well integrated with each other. Couchbase offers a more self consistent set of features that work well with each and industry standards as well. For example Couchbase is using SQL for query reducing the learning curve to use it, whereas Mongo has its own query language that everyone has to learn anew.
Quickest way to get started
Create a docker-compose file with the following content:
version: '3.3'
services:
couchbase:
image: couchbase
restart: always
ports:
- 8091-8094:8091-8094
- 11210:11210
Bring up docker-compose in its own terminal window.
docker-compose up
This will keep it running with the logs rolling in the terminal, which I find very useful. This is what it looks like as it starts. It is telling us that we should point our browser to http://localhost:8091, when running it like this in Docker:
This will bring up the configuration tool, which allows setting limits for the different Couchbase features. If you are strapped for memory when running inside a Docker container, I found that I could safely disable analytics and search.
Clicking Save & Finish will set up the database and put you into Couchbase’s GUI dashboard, which has a query analiser and many other features that will make it easy to work with the database in an ad-hoc manner.
You can now also connect to it from code via localhost!