My relationship with MongoDB can be divided into three phases. I’m on the third now, in which the product seems to be irrelevant for me. On this post you’ll see why.

First phase: fascination

I was really lucky in my first contact with MongoDB: it was used on a poliglot persistence architecture to deal with parts of the system in which the relational model was not a good fit. It worked as a charm: fast, easy to setup and use and had a really nice performance. Was perfect for that case.

I was dazzled with it: the fact that my main query language was JavaScript was an amazing experience. I’ve never thought that something like that could work so well. This was a period of discoveries in which I learned a lot about the product and how to manage the document model it presented me.

Second phase: reality

Maybe a better name for this phase should be maturity. At this moment I knew where and, even more important, where NOT use MongoDB. At this age you know that MongoDB is a nice product, but a product that you should use with caution. You know that the document model is great and solves a lot of problems for you, but not all: actually, quite a few.

The wakeup call for me was my own failures with it and, most of all, the failure of others. Mostly from people that I saw getting really excited about MEAN and trying to transform the world into a nail so that MongoDB could be the perfect hammer for it. It’s the moment where some facts get into your face and shout at you:

The relational model is not so bad as they sell. Actually, there’s a good reason why this is the most popular model and will be for a long time: it works . And contrary to what happens in the NoSQL world, we have a large knowledge base about good and bad practices to be applied to this model.

. And contrary to what happens in the NoSQL world, we have a large knowledge base about good and bad practices to be applied to this model. ACID matters. MongoDB have a little annoyance: you can’t create a transaction to deal with multiple documents. The problem is: the number of situations in which you must do that is huge and cannot be ignored.

All that talk about the huge performance you’ll get with MongoDB don’t matter so much if you don’t know in advance WHAT performance your system need.

On this phase all the excitment is gone, which is the best thing could happen to anyone. This is how you learn what the tool can and cannot do for you. It’s the best phase.

Phase three: irrelevance

Today MongoDB is irrelevant for me. Not the document model, but the product. One day I woke up and realized I didn’t need MongoDB anymore because the alternatives were far more attractive for my projects. It came in waves.

First wave: TokuMX

TokuMX is a fork of MongoDB that I like to call “the charming twin of MongoDB”. It uses the same communication protocols, have basically the same commands and is 100% compatible with MongoDB. But with some great advantages:

I can have full ACID transactions among multiple documents.

Way faster than MongoDB (50x times more performant according to Tokutek).

Consumes 90% less storage than MongoDB.

100% MongoDB compatible. All you have to do is replace your MongoDB instance with TokuMX, migrate your data (which is fairly easy) and you’re done.

And yes, it’s open source as MongoDB and have a free version which works extremely well. Of course it’s not a perfrect solution. It still have two limitations:

There’s no Windows distribution.

The Java libraries today doesn’t have native support for MongoDB ACID implementation. You can still use it, but still requires some boilerplate code.

TokuMX was the first time MongoDB seemed irrelevant for me. Of course, this can be temporary: MongoDB can still beat TokuMX on a future release. But only in a future release. Today it can’t.

Second wave: PostgreSQL

If TokuMX made MongoDB irrelevant for me, PostgreSQL 9.2 reinforced this impression. Since version 9.2 PosetgreSQL offer support for JSON and JSONB (JSONB support was actually added on the 9.4 release) data types. It’s an interesting solution because with it I can get the good parts of the relational model with the flexibility of the document. All of it on the same product. Nice!

Ok, but MongoDB still was more performant than PostgreSQL. I said it was, because since version 9.4 of PostgreSQL that became history: recent benchmarks show that PostgreSQL is now way faster than MongoDB dealing with JSON data types. I never compared PostgreSQL with TokuMX, but given that both are now more performant than MongoDB, I think you got my point here.

Conclusions

Comparing MongoDB with TokuMX and PostgreSQL makes the choice for MongoDB a hard one. It still is a nice product, and of course it will evolve to compete with these alternatives, but now it got a third place at most. Let’s wait to see what 2015 will bring for MongoDB.

Related Posts via Taxonomies