Why NOT to use MongoDB

5th Oct 2016

This article is the second in a 2-part blog series about MongoDBPart 1: How to use MongoDBPart 2: [you are here] Why NOT to use MongoDB How did you feel about the first article?....Did you agree with the statements?...Or did it make your toes curl because you really don't agree with the use of MongoDB? This article brings some balance -MongoDB is great for use in Web Applications, especially when you need to store document based data and don't want to be restricted by tables.However, there are voices (fairly loud voices actually) that speak of the reasons why you should NOT use MongoDB. discover what the experts say about

Let's have a look at some resources to find out why people world recommend against using MongoDB

QUORA

Quora: http://www.quora.com/In-what-cases-is-it-not-so-good-to-use-MongoDB

Dwayne Charrington, Front-end Web Developer

If you need table joins it is kind of weak. MongoDB isn't for relational data purposes.

MongoDB is fast because it sacrifices ACID compliance. Writes cannot be guaranteed if you want to keep them fast. There is support for transaction like queries like MySQL, but they're not as robust or secure.

If your data is relational (one or more rows belong to other rows) you can use sub documents which are nested JSON objects, but you sacrifice relating that data to anything but the parent object it is embedded in.

Some really good comments in this LinkedIn discussion:

https://www.linkedin.com/grp/post/4766229-211728149

MongoDB does not support transactions, so it is not suitable where it is needed. You can imagine money transfer or other complex operations. You can create something similar by yourself, but it is not supported from the core.

when you do not need horizontal scaling for your application

when your business needs can be efficiently solved in traditional way

when you do not have skilled personnel to support and troubleshoot setup

when total cost of support solution based on mongo will be higher than reliable alternatives
Non-relational, foreign-key-constraints, consistency, schemeless, transactions, limit of doc size, - all these features can be reasons why you should not use mongodb. So, choice of db server depends on the application.
SQL databases have benefits that come from maturity: lots of people who understand them operationally, developers who know how to use them, frameworks such as ORM that make it easy to use them.
Other NoSQL databases have advantages too. for example: (1) some folks argue that Cassandra is more scalable (2) Neo4j works well for Graph data (3) Redis is probably faster ...
Distributed transactions have definitely fallen out of favor as the coffeeshop example illustrates. There is also the "Ebay doesn't do two phase commit article". But transactions that involve a single server are still incredibly useful. Or put another way: if one day you discover that you need them and your database doesn't support them then you are probably in a world of pain.
Every database SQL or NoSQL has a particular set of trade-offs. And what's the best fit for your application depends very much on your requirements. Moreover, its possible that a polyglot persistence approach (http://slidesha.re/YZZqEl) where you use a mix of databases might be what you want. Or just a single MySQL database. It really does depend on your app.
Rant:
For Server Density, MongoDB has been an excellent tool. We really understand how it works and it works very well. We use it for many different things including storing historical time series data for server metrics, our core app data store and for simple queuing. It's also benefited us on a marketing front as we have grown with new MongoDB releases and have been able to talk about them at conferences and user groups.

BLOGS

David Mytton actually gives a nice overview of reasons why other people don't like working with MongoDB. You can read his conclusions and comments here:

https://blog.serverdensity.com/does-everyone-hate-mongodb/

(Just be aware that this post is from 2012 the overall sentiment might have changed by now as most of the security and lock issues would have been fixed by now (one would hope/think). After all - there are so many large scale and successful implementations that we can learn from.

Sarah Mei is one of the most vocal people against the use of MongoDB. Her article is interesting to read (and yes - I also enjoyed reading the comments... but then again, I suppose that everybody is entitled to an opinion?!)

What I like about Sarah's article is the clear and easy to understand analogies and explanations she uses.

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

Planet Cassandra gives a clear overview as to why you shouldn't use MongoDB. Of course they would prefer you use Cassandra " I hear some really tough stories about how it seemed to be a great fit when they started, only to find out it wasn't matching the scale they needed."

You have been warned, this article is biased, but still gives a good overview of reasons why people should or shouldn't use MongoDB.

http://planetcassandra.org/blog/mongodb-this-is-not-the-database-you-are-looking-for/

Enjoy reading these articles!

BONUS: A few videos on YouTube explaining MongoDB

YOUTUBE

MongoDB Youtube channel https://www.youtube.com/user/MongoDB

MongoDB tutorial for beginners: https://www.youtube.com/watch?v=1uFY60CESlM