Problems with MongoDB

Problems with MongoDB

March 20, 2017

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.

Join the conversation...


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.
Posted by Adoop Bimarthi on May 11, 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.
Posted by Rachel M. on April 19, 2017
good read. mongoDb is great and has proven to scale well, but such issues can arise.
Posted by Sundari on March 21, 2017

More by the stackchief