Does MongoDB Overstate The Applicability of Its Database?

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

We live in a time where many database vendors overstate the use cases for their databases.
Is MongoDB another example of this overstatement?

Introduction

Many RDBMS vendors are fighting back against multi-base offerings by stating that customers can perform non-RDBMS processing in their databases. IBM has enlarged the footprint of DB2 but adding AI, which we cover in the article How Reality-Based is IBM Adding AI to DB2? It is curious to now see an exaggeration of the proper use of databases coming from open-source vendors.

MongoDB’s Statements Around the Appropriate Use for Their Database

MongoDB does not merely state that its database is useful for traditional NoSQL use cases but proposes replacing even application databases. MongoDB has been able to do this because (in part) their introduction of transactions in 4.0. Most NoSQL databases cannot perform or manage transactions. And transactions have always been the dividing line between databases that can support applications and those used for analytics or other purposes. And performing transactions means the database is ACID (atomic, consistent, isolated, durability). An ACID-compliant database posts transactions correctly 100% of the time and has a mechanism for rolling back transactions that are not completed.

Transactions are aggressively promoted on MongoDB’s website.

MongoDB’s marketing mainly describes its database as a replacement for every type of database processing category. This is explained in the excellent graphic from Nemil.

As one can see, MongoDB is recommended on the left of just about everything. For this to be true, MongoDB would have to be superior to every other database type, and it would mean that MongoDB has virtually no weaknesses.

Nemil states that MongoDB holds to the concept that their database is so revolutionary that the best approach is to replace most of the current database with their database. Knowing what MongoDB is, a document database, it is challenging to see how this can be true. From a design perspective, a document database is more straightforward to develop than an RDBMS.

Document databases are hierarchical, and hierarchical databases preceded RDBMSs and eventually lost out to them.

Here is an example of a hierarchical schematic from the MongoDB website.

MongoDB as the Universal Database?

From the Nemil article, the following is explained about MongoDB’s view of its database.

“Even today, 10gen argues that 60-80% of “applications” benefit from using it. Going further, MongoDB’s CTO feels that nearly 90% of database installations would benefit from switching to MongoDB. Many engineers I know — who value MongoDB at their own companies — would disagree with 10gen’s view.”

This type of overstatement generally leads to problems, and this is expressed in the following quotation, also from Nemil.

“The MongoDB docs tell you what it’s good at, without emphasizing what it’s not good at. That’s natural … But as a result, it took us about six months [and] a lot of user complaints … to figure out that we were using MongoDB the wrong way.” – Sarah Mei

Go to top

Conclusion

Comments about the universality of one database type should be taken with a grain of salt. At Brightwork, we recommend using the best database for the task and the example of database processing. However, what pushes back on this is IT departments’ desire to narrow the tools they use as much as possible.

Nemil’s article on this topic is highly recommended.

References

https://www.nemil.com/mongo/3.html

https://www.mongodb.com/transactions

https://docs.mongodb.com/manual/applications/data-models-tree-structures/

https://docs.mongodb.com/manual/core/write-operations-atomicity/