MongoDB vs Couchbase – part two

This is the round two in comparing MongoDB vs Couchbase. In round one, we saw the landscape of document databases and what makes them different and attractive in comparison to RDBMS.
Featured story Blog
MongoDB vs Couchbase – part two

This is the round two in comparing MongoDB vs Couchbase. In round one, we saw the landscape of document databases and what makes them different and attractive in comparison to RDBMS.

We’ll start with basic concepts in both databases. Both databases are used for storing (JSON) documents. MongoDB, in fact, stores BSON, which is (kind of) a superset of JSON specification.

MongoDB – Basic Concepts

BSON, Collection, and mongo shell

As already mentioned, MongoDB stores documents in BSON format. Documents which are semantically similar (that have more or less the same schema) are grouped into a collection. For example, developers should store documents that describe users in collection users, documents that describe cars should be stored in collection cars and so on and so further. Every document has an _id property, which is an identifier of the document and is unique in the collection. If _id is not present when a document is being saved into collection, MongoDB will generate one.

MongoDB shell (invoked with mongo command from the Linux command line) can be used to query and update data in MongoDB. What is cool is that MongoDB shell is a JavaScript interpreter so you can call MongoDB commands from JavaScript loops, which is quite useful for ad hoc data creation and playing around.


Also, code completion is very useful for a lazy engineer such as me.

Couchbase – basic concepts

JSON, bucket, and cbq

In Couchbase, JSON documents are stored into buckets. However, unlike MongoDB’s collection, a bucket usually does not contain only similar documents. In a way, it is similar to the concept of a database in RDBMS. Except that the ID of a document must be unique on a bucket level, which is not the case in RDMBS where ID is unique on table level. So, one bucket usually contains all kinds of documents with fairly different schemas. Good practice is to add the type attribute to ease the fetching of the documents and index creation. One more difference compared to MongoDB is that generation of ID is the developer’s responsibility.

For CRUD operations with Couchbase, cbq tool is used. There is also a GUI for running queries – Query Workbench, but it is only available in Enterprise Edition.

Query Language

MongoDB uses its own query language that is created with documents in mind. It’s really simple to use:

* db – denotes the currently selected database. To select a database use command: use name_of_the_db;

* users – name of the collection in the selected database

* find – method on a collection that selects the documents to be returned (it actually returns cursor with the selected documents, but let’s keep it simple)

Two documents are passed as arguments to _find_ method:

{ firstname : “Alice”, birthyear : { $gt : 1986 }} – the first one specifies what kind of documents we are searching for. In this case we are searching for users with first name ‘Alice’, born after 1986.
The second argument is a projection:
{ username : 1, firstname : 1, lastname : 1 } – it basically says return only username, firstname and lastname attributes for the selected documents (and id which is returned by default).

So, MongoDB uses document structure to specify a query. They have very detailed documentation and tutorials.

Inserts are also very simple:


Couchbase introduced a N1QL – SQL-like query language, in version 4.0. The same query from above would look like this in N1QL:


This makes the transition to Couchbase from RDBMS much easier. However, the downside of using SQL with documents are the INSERT statements that look like this:


Which is quite verbose and hard to remember, and cbq shell does not offer code completion in 4.1.1 (the latest version that is free to use).

If you want to learn more about N1QL, there is a good blog post on that subject. Speaking of which, blog posts are usually much better and very often the only source of information about N1QL.

Another way to fetch documents from Couchbase is using MapReduce Views.


MongoDB uses a B-Tree data structure for its indexes, which is a quite old and battle-proven way of maintaining database indexes. That is what relational databases use. When combined with correctly modelled data in MongoDB, it provides quite a nice performance.

Unfortunately, the whole point of adding the Index part in this blog post is only because of Couchbase. Something is rotten in the state of Couchbase indexes. Unlike MongoDB, Couchbase’s indexes are implemented using skip lists. Skip lists are usually used in in-memory databases. And Couchbase, being memory-first, happens to use skip lists for indexes. It’s a rather young data structure, at least when compared to B-trees (which are 20 years older). So there are probably still some flaws and serious performance trade-offs in different implementations.

Why am I mentioning this at all? Because I lost weeks figuring out how to do some basic queries that will utilize the order of the elements in an index. For example, it was an epic quest trying to get 50 newest documents, because the query involved ORDER BY timestamp, and it turned out that the ORDER BY clause does not work quite well with indexes in 4.1.1 CE.

Even when a query uses an index for fetching data, it is an order of magnitude slower than MongoDB. But to be clear, Couchbase claims that it is, indeed, slower on a single node environment in comparison with MongoDB, but that it outperforms MongoDB in cluster deployment.

Anyway, asking for help on Couchbase forums for very simple things because of poor documentation/implementation is not quite… well… scalable solution.

Documentation and community

Having well-documented tools and large community are very important criteria when choosing a technology stack.

MongoDB’s documentation is one of the best I’ve ever seen. It is quite thorough, with lots of examples. They also have high quality free online courses which provide a solid foundation of knowledge and confidence when working with MongoDB.

On December 26th, 2016, there were 74,558 questions on StackOverflow tagged with mongodb.

At the same time there were only 2,155 questions tagged with couchbase. Combined with very poor documentation, choosing Couchbase for building anything with a deadline is a nice way of ruining your mental health.

But take my opinion with a grain of salt. I love simple systems and I prefer having a piece of toast and watching evening news instead of discovering workarounds and how undocumented features work. But if you like a bumpy ride, go for it!


MongoDB has been production ready for a long time (shut up, haters!), and 3rd party tools, as well as built-in ones, are decently built and documented. Robomongo is an excellent admin UI for Mongo. There are several embedded MongoDB implementations, meaning that they can be started and shut down in integration tests as part of the build process.

There is no Couchbase version that can be run as part of a build process yet. Also, internal tooling (like export and import tools) is not as powerful as Mongo’s. For example cbdocloader tool which is used to import JSON into database cannot import JSON array (unlike mongoimport). I am not even sure if you can export data as JSON in 4.1.1.

Couchbase’s cbq tool (in CE version) cannot run query and direct the output to the file. Like mongo shell can (with –eval parameter).

All in all, the tooling in Couchbase gives a sense of unfinished products.

However, the strongest selling point of Couchbase are the following tools:

– Couchbase Lite – mobile version of Couchbase

– Sync Gateway – used for synchronization of Couchbase Lite with Couchbase Server

Together with Couchbase Server, these make a very powerful combo. You get out of the box synchronization across devices and server database. That sounds very promising.

Pricing Model

MongoDB’s business model is: give the database for free and charge for additional tooling and support. This seems to have become a standard revenue model with companies built around open source tools.

Couchbase works differently. They provide older versions for free, currently 4.1.1 Community Edition (CE), and charge for the newest version, 4.5.1 Enterprise Edition (EE), and support is paid of course. EE version can also be used in any non-production environment. The problem is that the CE version is currently quite buggy and hardly usable for some cases (like fetching 50 newest documents?!), so it seems like Couchbase wants you to pay for basic features that any other database can provide for free. And, yes, the documentation sucks, so you better pay for support. Maybe it’s just my millennial entitlement, but I don’t like the idea of paying for support for trivial use cases. I want to have a chance to learn stuff and use the tool for solving business problems on my own.


The feeling is that MongoDB is built to be really easy to use. Starting from generation of _id if it is missing, to the fact that literally zero configuration is needed to just start using it. On the other hand, Couchbase gives the feeling of a very tunable solution. Each service in Couchbase Server can be scaled separately, there are a lot of configuration options, it promises near-linear scalability. However, it’s still a risky bet. Interesting, but not production-ready technology. If it delivers what it has promised, it might dethrone MongoDB from the schemaless throne of document-oriented databases.

But for now, Couchbase is just a prototype and I would not recommend using it for anything that needs to be delivered in a timely manner. While working with it, I felt that I was constantly fighting against Couchbase, and I was never sure if I was using it correctly (because of poor documentation) or it was just a buggy behavior (because of poor implementation). And it was really tiresome and time consuming to consult Couchbase forums for every problem I stumbled upon.