Problems with MongoDB

Last modified: March 20, 2017

Ask all your coding questions @

UPDATE: This article is not suggesting MongoDB is an inferior option for data storage. Its goal is to point out potential pitfalls and start conversations. Check out our section on MongoDB for more articles on the benefits of using MongoDB.

MongoDb is a popular option for database storage. It's easy to learn and faster than competing RDBMs. It's denormalized, meaning data is stored in a nested document structure rather than relational tables. This makes for faster lookups as Mongo doesn't rely on expensive join operations seen with MySQL and other database engines. Despite such strengths, there are several problems with MongoDB that one should consider before using it as a database engine.

Problems with Reliability

MongoDB writes are asynchronous by default. The main advantage of this is you don't have to wait for confirmations for every insert or update operation before the next one starts. This makes updates faster but less reliable. Even if some of the updates are unsuccessfull, the write operation will still partially succeed.

This differs from more traditional RDBMs like Oracle and MySQL, which make use of transactions to rollback operations when things partially fail. With these engines, it's an all or nothing (versus the fire and forget approach taken by Mongo). While this may be slower, it's a more consistent and reliable way to perform write operations. When things only partially work you can end up with data inconsistencies and buggy data.

Problems with Schema-less Design

Since MongoDB is denormalized, it doesn't adhere to a relational schema. Everything is stored in nested JSON objects called documents. While this allows for greater flexibility with your data models, it forces more schema based design decisions on the app logic rather than the db. For example, say you want to access an email address from a user object with:

var email =

This statement will break for all user objects that don't have an email attribute. While one can assume that every user for their app should have an email, there is nothing that validates the existence of this attribute on the backend. Without a schema in place, the rules and regulations of your data models are dictated by your app logic rather than the db itself.


Although such problems exist there are plenty of third party libraries for working around these issues. Solutions do exist for making asynchronous writes synchronous. Libraries like Mongoose bring ORM to MongoDB and allow for pre/post save operations that validate data. Although such libraries address the pitfalls of MongoDB they still don't provide the security and reliability of transactions with other engines. Be sure to account for these potential issues before using MongoDB with your app.


October 16, 2017
You know what else has problems with reliability? This website does. Just look at the fine print disclaimer at the bottom of every page:

"StackChief does not guarantee full accuracy of it's content."
September 9, 2017
UPDATE: mongoDB has solidified its spot in big data. It's important to remember that the issues experienced with schemaless design can be compensated for with SQL like engines and other abstractions.
August 11, 2017
MongoDb is great as a NoSQl, denormalized option for data storage. in terms of big data, its great for reading large data sets quickly. MongoDb fails miserably from a relational standpoint. it's really hard to interact with other documents unless they are nested within parent documents. also sub arrays or long lists of information stored within documents can get really annoying really fast. if you are going to use MongoDb, use it for READ ONLY operations. don't try to be a hero :)
June 20, 2017
there are absolutely no issues with using mongoDb. it can do anything you need it to do. i will agree that it's inferior to RDBMs for the normalization of data, however most of the projects i work on these days require big data queries and fast reads. this is what mongoDb is ideal for..but don't get it twisted you can still use MongoDB for any use case in my opinion.
Adoop Bimarthi
May 11, 2017
if you think there are issues with MongoDB then you aren't using it correctly or in the right context. Using noSql is great for fast lookups etc but should be avoided if you need the relational aspect. Mongoose can make MongoDb a lot easier by bringing an ORM to table, but it's still no comparison to the rollbacks etc you will get with Oracle or other RDBMS.
Rachel M.
April 19, 2017
it's really more SQL vs NoSQL...if things like transactions and rollbacks are important to you, then def use a RDBM/SQL DB. if your app is largely read only and you just want to display lots of records really fast then go with NoSQL (MongoDB)...also it being all JavaScript is a huge plus for front end guys.
March 21, 2017
good read. mongoDb is great and has proven to scale well, but such issues can arise.

You might also like: