The growing irrelevance of MongoDB

The growing irrelevance of MongoDB

My relationship with MongoDB is divided into two stages that I believe are normal between various users of this product : wonder and reality. In this post I expose the third stage I am experiencing : irrelevance.

I had a very lucky in my first contact with MongoDB: used it in a polyglot persistence architecture in which he handled the cases in which the attributes of some entities varied greatly. It was a very successful experience: the varying too was on MongoDB and the rest in a relational database.

At the time I was amazed with the performance of MongoDB and the ease of installation and configuration. Besides the syntax of queries I looked quite attractive at the moment (JavaScript!). The gain I saw at the time (and still see) the emergence of MongoDB (which was probably the main responsible for the popularization of NoSQL solutions) was the fact that we agreed to such a common error that neither we considered as such, not all data structures must be stored in tables. Suddenly we all developers, we realized that we had turned the universe into tables and that was not good.

There follows that phase of trials in which you wonder what you can do with the new tool. There will be thousands of posts on the Internet reporting legal experience and this ends up feeding the wonder itself that we have with the new tool.

As time went by saw the emergence of technologies such as MEAN, extremely interesting but often led those who had adopted (in a state of wonderment) to repeat our mistake with the adoption of the relational model: MongoDB as a universal solution to all problems persistence.

I also saw some Java projects adopting MongoDB as the only solution and paying a high price. It was clear that in many situations MongoDB was no longer a solution to become a problem (and large). The reasons were obvious, but the hype ended up blinding many people some fundamental aspects:

The relational model is and will remain relevant for ages: if you need relationships, MongoDB is not your friend. And make no mistake: data redundancy in the form of embedded documents is not a solution, but a solution disguised problem in most cases. Referential integrity is important, it is not there for nearly four decades by fad.

(Do not believe the bullshit that is so different it is good and you are with a backward mentality)

(Implement referential integrity in hand is a VERY sad experience)
MongoDB had no transactional control BETWEEN documents: ok, you get an excellent performance by not having a full ACID, but when you have to deal with more than one document in the same processing unit ACID is VERY lacking.
Still there is a long tradition in maintaining databases based on documents, so there is still no proven best practices for time, but declared by either that self proclaimed “authority on the subject.”

(Suspected of “gurus”)

The fantastic performance argument MongoDB is fallacious if you do not know beforehand what the performance that your project needs . Having the fastest is not to have the best solution.

This is the stage where you start to know clearly where the tool may or may not be used .

I confess I did not expect this state in my experience with MongoDB, but it was such a natural way that one day I woke up and realized it would not adopt it as a solution. Note: consider irrelevant MongoDB product, not the persistence model based on documents. This irrelevance manifested itself to me on two occasions.
First: TokuMX


Some of MongoDB limitations quite hindered my work. Among these, the main one was the fact that no transactions when manipulate more than one document in the same processing unit. Seeking alternatives found TokuMX: a MongoDB fork that was attractive for the following reasons:

I have enabled transactions across multiple documents in a single processing unit.
orders of magnitude faster than the MongoDB.
Consumes a significantly smaller amount of storage space (this could prove in practical).
100% compatible with MongoDB: just replace my instance of MongoDB by TokuMX my clients even notice the change and already have the above gains.

From this moment TokuMX took the place of MongoDB in my projects . Of course he was not a perfect solution. Some of its limitations could be quite boring :

There is no distribution of TokuMX for Windows.
Java libraries used to deal with MongoDB not take advantage of transactional support TokuMX . Spring Data does not support and drivers that used neither. Despite this , you can take advantage of this feature by sending commands to the DBMS , but is soooooo not a elegant solution as it should be .

However the irrelevance of MongoDB right now is temporary. Nothing prevents that a new version that overcomes the TokuMX .
This was the nail in the coffin . PostgreSQL since version 9.2 already supports the type of JSON and JSONB data in your tables . It is an interesting solution for mixing in the same DBMS the persistence model based on documents and relational . All this within one year of architecture whose quality is already proven to there .

The only point that MongoDB held in this case was his performance. It was because in 2014 the 9.4 version of PostgreSQL exceeded ( and ) the performance of the MongoDB . Doubt? Here’s the link. Not yet know how PostgreSQL compares to TokuMX , but the simple fact of being able to use a single DBMS instead of two is already a very interesting advantage for me . Add to this the fact that the complete and affordable ACID in a simple way , PostgreSQL has just taken the place of TokuMX .

In conclusion

If you compare the MongoDB with market alternatives , you will see that most of its relevance is gone. I do not consider it a bad product , but lower than the developments that came following ( TokuMX and PostgreSQL 9.4) . If there are superior solutions and a more interesting cost , what can I do now is just wait to see how MongoDB will evolve in 2015 and beyond.


Please enter your comment!
Please enter your name here