Why MongoDB Didn’t Conquer the World: Part 2

My previous blog post introduced MongoDB, which was one of the first ‘not only SQL’ (NoSQL) databases. The blog post explained how MongoDB became almost synonymous with the NoSQL movement and how MongoDB’s rival enemy PostgreSQL responded. This blog post clarifies more reasons regarding MongoDB’s failure and reveals a glimpse of the future of the DBMS market.
New Kids on The Data Block
When MongoDB was launched, the NoSQL ecosystem was just developing. MongoDB’s competitors were old relational databases that had been on the market for ages. However, where there is demand there will be supply.
Completely new kinds of NoSQL-databases arose in the late 2000s and early 2010s. A good example was a real-time data and performance-optimised, key-value database Redis. The column-family database Cassandra, originally designed by Facebook, was another new competitor. Cassandra focussed on massive datasets and a linear scalability, and was the rational choice for huge Big Data projects. The dramatic growth of content and data search created specialised search engines such as Elasticsearch and Solr. In addition, new time-series databases like InfluxDB  were born, and they suit IoT- and sensor-based worlds extremely well. All the new NoSQL databases were exceptional in their own area and attracted old MongoDB customers.
Cloud-computing platforms, such as Amazon Web Services (AWS) and Azure, also launched their own database services. These platforms offered an easy setup, an unlimited scaling option, and a refreshing pricing model. However, advanced competitors were not MongoDB’s only enemies.
MongoDB in the Mirror
After initial enthusiasm, the first discords arose in the MongoDB-related projects. Software developers suffered various and often unusual problems. Compared to other trendy technologies, MongoDB seemed untrustworthy for products meant for a real environment.
With MongoDB’s dynamically typed schema—or in other words, “schemaless”—the benefits are easy setup and data modelling flexibility. However, this doesn’t come without a cost. A schema guarantees that the data can be stored in a consistent format. Without a schema, the responsibility of database consistency shifts to the application. A schemaless database makes the code more error-phone, increases code duplication, and easily creates deeply-nested structures.
The number one priority all databases is to store the data and keep it safe. Rumours started to spread that MongoDB’s consistency model was broken by design and that it might lead to data loss. MongoDB was accused of a lack of the product development discipline, monetising the NoSQL-market, and a slow customer support. In the end, MongoDB, Inc.’s CTO replied to the rumours in an open letter. It remains unclear if MongoDB can really lose the data, but the scandal damaged its reputation badly.
MongoDB has also suffered multiple growing pains. Lockdown problems, complicated sharding, bugs in replications, and unsafe writing are just a few to mention. In response to a critique, MongoDB released major updates, published support blogs, and organised conferences and hackathons. Unfortunately, this did not change the general opinion.
Finally, the developer community turned against MongoDB. Blogs such as Why You Should Never Ever Ever Use MongoDB, Goodbye MongoDB Hello PostgreSQL, and MongoDB Frankenstein Monster NoSQL databases strengthened the negative atmosphere. The Reddit message board even contains a huge joke thread about MongoDB’s weak points.
Reality Bites
MongoDB started to become sandwiched between traditional relational databases and new NoSQL databases. Many products still need strong relational consistency, reliability, and referential integrity. Alternatively, startups are looking for more database as service solutions.
A microservices architecture encourages developers to use multiple databases in one system. With a microservices architecture, it’s possible to use MySQL for the business data and Elasticsearch for the logging purpose. MongoDB’s ‘something for everybody’ strategy did not seem valid anymore.
The database ecosystem will fragment even more in the next years. MongoDB will remain in history as a main character of the NoSQL movement. Sadly for MongoDB, history has taught us that the first rebels are not the leaders after revolution.
Graphic Design
Esa Lahikainen
References
https://redis.io/
 http://cassandra.apache.org/
https://www.elastic.co/products/elasticsearch
 http://lucene.apache.org/solr/
https://www.influxdata.com/
https://aws.amazon.com/rds/
https://azure.microsoft.com/en-us/services/sql-database/
https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-using-a-schemaless-database/
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
https://news.ycombinator.com/item?id=3202959
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/
http://developer.olery.com/blog/goodbye-mongodb-hello-postgresql/
https://www.linkedin.com/pulse/mongodb-frankenstein-monster-nosql-databases-john-de-goes
https://www.reddit.com/r/ProgrammerHumor/comments/62mfrx/what_is_mongodb/