The Dark Side of the MongoDB
Is MongoDB the right choice for your application? Are you aware of disadvantages?
Disclaimer: I’ve worked with ME*N stack for +2 years in production in a well-known company and this is the summary of problems that we’ve endured.
One of the most powerful things about MongoDB is the way it stores the data in a single collection. MongoDB lets you store the data in a de-normalized or normalized way, but most of the time both of them are EVIL!
- Why MongoDB way of de-normalizing may be bad?
Generally, the main goal of de-normalizing data is achieving better performance by removing JOINs. However, de-normalizing the data is recommended only when sub-fields ( like “address” and “contact” in the above example ) will be needed when the user is accessed. Therefore, accessing “contact” and “access” independently would be painful.
What should you do if you need these fields independently?
MongoDB suggests to use normalized models, which is just like any traditional RDMS!
In a real-world scenario, most of the time you need access collections separately, so MongoDB has no advantage here! But that’s not all. If you use this approach in MongoDB, you’ll also lose performance, since relation and joins are something RDMS are created for, while MongoDB added $lookup feature on version 3.2 which suffers from a limitation on sharding too!
Efficiency
Many folks think MongoDB is one hell of efficiency, however, that’s a not true at all.
Here is a benchmark by arangoDB which compares the performance of several databases:
And here is another benchmark from enterprisedb which compared MongoDB with Postgres:
As you can see, MongoDB may not be good choice if performance is a concern for you!
Transactions: ACID (Atomicity, Consistency, Isolation, Durability)
Handling transactions is a must-have feature in enterprise apps, especially when data is valuable. Starting version 4, MongoDB introduced Transactions API which seemed cool at first, however, there is a big warning message in Transaction API:
Important:
In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transaction should not be a replacement for effective schema design
….
Is that all? No
You’ll also need a Replicaset to use transactions API! If you use transactions on a single server, you’ll get errors. There are many limitations that’ll make you regret using Transactions API at all.
Flexible Schema
When using the embedded way, the flexibility of MongoDB is cool. But it also lets you insert any kind of data wherever you want. With this feature ( or bug?) you’ll lose the database-layer validation and everything must be double-checked in the application layer.
With every change in your document model, the best practice is to have a migration to make all data share the same structure. Otherwise, you’ll end up with tons of if-else statements and dirty codes.
Is MongoDB that bad?
MongoDB has its advantages and disadvantages. It’s not a bad DBMS, however, IMHO MongoDB shouldn’t be used as the main database of an application, unless you exactly know what your application will do and you are aware of its weaknesses.
What do other people think about MongoDB?
At the end of this article, I would like to add some references from other people who share my pain:
