Problems with MongoDB
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 = user.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.
Conclusion
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.
