Why should I use MongoMVCC

Why should I use MongoMVCC?

Here are the five top reasons why you should use MongoMVCC:

1. Because it's fast.
   MongoMVCC is based on MongoDB which is one of the most scalable and high-performance NoSQL databases on the market.
2. Because it never forgets.
   MongoMVCC keeps a complete history of all your data. It enables you to access old versions of your documents at any time.
3. Because it's rock solid.
   MongoMVCC uses the principles known from distributed version control systems such as Git. Documents added to the database will not be visible until you make a commit. This guarantees consistency and full isolation. Moreover, it allows you to create branches containing different versions of your documents.
4. Because it's lock-free.
   Even though MongoMVCC provides consistency and isolation it completely works without locks. This assures high performance on multi-core systems.
5. Because it's cool.
   MongoDB is cool (I'm sure you agree with that), MVCC is cool, ergo MongoMVCC is cool! :-)

Disclaimer: There's nothing such as a one-fits-it-all DBMS. One of the nicest things about NoSQL databases is that you have a very large number to choose from and there is almost always one solution that meets your requirements. So, please first think about your requirements and then check if MongoMVCC is the right tool for you. Please also make sure you read the Reasons for not using MongoMVCC section below.

Why not plain old MongoDB?

MongoDB is by no doubt one of the most elaborate NoSQL databases. Nonetheless, it is also very simple. There's nothing such as versioning nor does it implement the ACID paradigm. Of course this is also one of the reasons why MongoDB is so fast. Usually, you can only implement these features with locks which would make the DBMS a lot slower.

However, MongoMVCC works completely without locks. It is almost as fast as plain old MongoDB, but also offers features such as consistency and full isolation (known from ACID). Moreover it allows accessing the full history of your data. It does this by mimicking a distributed version control system. Documents added to the database will only be visible after you made a commit. Committing to the database is of course an atomic operation--i.e. only one more document will be added.

Why not CouchDB?

You may have heard that CouchDB also implements the MVCC paradigm and you might ask yourself what's so special about MongoMVCC. Here are some answers:

1. MongoMVCC uses MongoDB underneath. Please read the MongoDB vs. CouchDB comparison for more information about the advantages/disadvantages of these two DBMS.
2. In our opinion, one of the most important reasons why someone might want to use MongoDB instead of CouchDB is that it allows ad-hoc queries. MongoMVCC also allows that.
3. In CouchDB multiversion concurrency control (MVCC) is an implementation detail which is not directly visible to the user. In MongoMVCC the MVCC paradigm is one of the core concepts. This enables you to access the complete history of your data.
4. Since MongoMVCC implements the principles of a distributed version control system, it introduces features such as branching which are not available in CouchDB.

Reasons for not using MongoMVCC

Of course, every technology has its disadvantages which you should consider before using it. MongoMVCC is by far no exception. Here are some reasons why you wouldn't want to use MongoMVCC:

1. Several optimization strategies make MongoMVCC almost as fast as plain MongoDB. However, when performing database queries, it needs to filter out documents not belonging to the branch or version currently checked out. This adds a slight overhead. We tried to minimize the overhead as much as possible and more optimization strategies will follow in the future, but if you have high-performance requirements and are in need of every millisecond then MongoMVCC might not be the right tool for you.
2. Since MongoMVCC keeps the complete history of your data, the database might grow very fast. Of course, it tries to reuse existing documents in subsequent commits, but if you just do the slightest change to a document, MongoMVCC will copy it completely. The document's old version will stay untouched. Apart from that, MongoMVCC keeps some redundancy in order to achieve a better performance. For example, each document will contain information about its lifetime. This information is not visible to the application. Nonetheless, it's there and it uses some space.
3. In order to provide complete isolation, MongoMVCC introduces its own interface for accessing the database. This means that you cannot use other tools that access the API of the MongoDB Java driver directly (such as object mappers). The main issue that has to be solved is that the MongoDB Java driver mostly relies on abstract base classes and not interfaces which we could override. Apart from that, the MongoDB Java driver's API is too broad for MongoMVCC, meaning it provides too much operations, which we definitely have to hide in order to implement the MVCC paradigm. If this is a problem for you and you still would like to use MongoMVCC then please contact us or the MongoDB Java driver team.