MongoDB Pros and Cons Explained For Remote DBA Experts

While a lot of IT managers are switching to MongoDB because of the many perceived advantages, it is quite likely that many would not have perhaps stopped to weigh the advantages and disadvantages of their decisions. Since the technology is relatively new and not familiar to most, its adoption and implementation into a production system could easily end up being catastrophic. Some advantages and disadvantages:



The process of storing data across a number of machines is known as sharding. The load balancing process represents MongoDB’s method of dealing with large volumes of data. When the data volume increases a lot it may not be possible for a single machine to store it in such as way that the read-write functions are within the acceptable limits. Sharding undertakes horizontal scaling by distributing the data across multiple machines in a manner that users get acceptable data throughout. MongoDB scores very heavily over conventional relational databases like MySQL due to this ability.


The beauty of the MongoDB system is that even though the data resides on multiple machines it is treated as it is on one machine. This results in MongoDB queries being much faster, especially when the data is in a true document form. When data needs to be emulating a model that is relational the code written ends up doing a large number of independent queries so that a single document can be retrieved.


When it is impossible to ensure consistent data structures for all the data, MongoDB becomes very useful as the database does not require the availability of a unified data structure covering all objects. However, having data that is consistent is a really good thing so whenever practical, you should always endeavor to apply a unified data structure. Having said that, MongoDB can be far easier to use and implement than a conventional RDBMS.


No Joins

Unlike in a conventional RDBMS, you cannot join data in MongoDB. This essentially means that whenever you do have such a need you will be required to make a number of queries and then arrange to join the data within your code manually and typically this leads to a reduction in flexibility upon any change in the structure and code that is both ugly and slow.

Memory Usage

Because MongoDB needs to store the key names in each document to cater to a situation where data objects are not necessarily consistent, it naturally tends to make more system memory demands. Users also need to deal with duplicate data because joining is not possible or the queries become slow as joining needs to be done from inside the code. In order to get around the problem of duplicate data, it is possible to store object references in MongoDB. However, the very indication that you may be doing this could possibly indicate that you would be better off with a relational database.

Concurrency Issues

In MongoDB when you do a write operation, the entire database gets locked to give it priority. Strangely enough, it has the result of not only locking all other write operations but also all read operations for all fields and not just the affected ones. The reader-writer lock on MongoDB while giving access to just one write operation allows concurrent reads. While many read operations may use a read lock, the write lock is exclusive and does not permit any sharing. The way MongoDB is programmed, write locks are given a preferential status when a read lock is also waiting for a lock.

Young and Not Evolved

In comparison with other relational databases, MongoDB is quite young having been born only in 2009. Consequently, the user base is as of now inexperienced and the body of knowledge on it is relatively less when compared to others. Because the coding is very much under development, professionals might not find the concept of beta testing enamoring at a time they are attempting to develop an organizational project.


To conclude, users attempting to switch to MongoDB should be aware of the many lacunae of the system. Being relatively young in its development cycle the database is relatively immature. The decision to use MongoDB should be based on the particular circumstances of the users and if they find that the advantages outweighing the disadvantages they should definitely try and leverage its strengths.