I’ve found many articles that talk about how bad Mongo is, and that it offers no advantages over other DBs and can cause all kinds of problems at scale. Many of these articles were from around 2014. Has anything changed since then about Mongo to alleviate some of these concerns? I’m curious as to why Mongo was chosen as the default database when it seems at least controversial as to how good of a database it is. Personally I have no experience with other databases, and I found Mongo very easy to work with within Meteor’s context, so it was surprising to read all the negativity about it. Anyone have thoughts on this? It’s clear that many people are using Meteor (and therefore Mongo, at least most of the time) in production, so it can’t be that bad right?
MongoDB is only bad, if you used it wrong - as any other db or tool in general.
It is a good fit for meteor, because it is easy to use, is schema-less and fits perfectly into the javascript-world (it’s query language is javascript after all).
It lacks however some features from other databases like manipulating multiple tables in the same query or automatic delete over relations (via foreign-key), (however i am not sure if this is still totally the case).
In mongodb you tend to do these things “in software”, means: in your application rather than in the database, which may confuse developers with strong sql-background… You rarely touch the database at all with mongodb. (You also never nead a ALTER TABLE…).
So in general mongodb is different than a relational database and its therefore also not the right tool when you have lots of relational data (i mean data with lots of relationships over multiple tables). On the other hand, many webapps do not really complex relational data and a simpler approach like mongodb is often a better fit.
If you also have much more “reads” than “writes”, mongodb is a solid choice and provides good options for scaling. Denormalisation (including dependend data into the same document or even copy it from other tables) is also a common practice if you need more read-performance or want simplicity. This also irritates SQL-developers, as they have learnt in school to normalize the sh*t out of their datamodels 
Background: I wrote this email in December 2015 to explain to our development team why we would continue to use MySQL instead of MongoDB with Meteor.
I note that this represents my personal opinions and does not in any way represent the views of MDG:
I also note that it is now August 2016 so some of the information could be a little out of date because it predated the release of MongoDB 3.2, but is still mostly current…
Why MongoDB Is Not The Way To Go
This is a question that I have spent much time looking into and I want to share the information I have gathered so it is clear to everyone.
Why did Meteor choose to embrace MongoDB?
*Meteor was designed to provide a better alternative to developers who were using the MEAN stack (MongoDB, ExpressJS, Angular, NodeJS) which had gained popularity in 2013. Hence, they needed to make it easy to cross over and port existing apps.
*Meteor was a new platform. As anyone developing a new platform knows, one of the most important goals is to gain traction and build a sustainable development community.
*MongoDB is easy to get up and running with, especially for newbies, as you temporarily avoid the need for tasks that require deep thought like schema design
GIven this, It was a logical move for the Meteor Development Group (MDG) to initially embrace MongoDB, though in their road map, it was always their stated intention to embrace other databases, especially MySQL and PostgreSQL.
But as we know, the technology that gets you up and running quickly is not necessarily the one that will scale to handle growth,
Ways that MongoDB is deficient to MySQL:
-
MongoDB does not support transactions - you cannot perform multiple data manipulation operations atomically. If there’s a failure or interruption, you will have to detect and clean up the mess yourself. This originates with the fact that Mongo was designed to be a document object-store.
-
MySQL lets you be very specific when choosing datatypes to store values. It supports a wide selection, including decimals and GIS datatypes.
It also lets you be specific about how you want them to be indexed. This reduces wasted memory and disk space and maximises query performance.
MongoDB does not offer these capabilities. When coupled with Meteor, it is limited to the 6 basic primitive Javascript datatypes (Boolean, Null, Undefined, Number, String, Symbol) plus two added ones (Date and Binary) implemented in Meteor.
-
MongoDB does not validate data like MySQL does. This has to be done in the application using a library like Mongoose or Meteor’s simple schema. This chews up the Node processes’ CPU time - the most precious system resource in a Node application.
-
Meteor’s MongoDB driver does not support minInterval throttling or programmable trigger conditions like numtel’s MySQL driver. It will read the MongoDB OpLog and needlessly trigger on any event in a collection, even if that event is irrelevant to the task.
Raising minInterval on occasions where there has been a big surge in demand has saved our arses several times and allowed our system to keep running.
The Meteor MongoDB driver could possibly be enhanced by adding support for these features, but it hasn’t happened yet.
Why things will keep getting better with MySQL:
MySQL 5.7 was released a month ago and Percona Server 5.7 Release Candidate was just released. These have two killer features: a JSON datatype and spatial indexing.
*Having this native JSON datatype will allow the Meteor Accounts package to be more easily ported to MySQL, as it avoids the need to substitute nested objects with additional tables.
*Having spacial indexing can greatly accelerate geofence-related calculations. Geographic points and shapes can already be stored using a special datatype. Now you will be able to do efficient searches to see whether a given point is contained within a shape, avoiding CPU/memory overhead in the application.
A few (but not all) relevant articles/posts I found:
*Why you should never, ever, ever use MongoDB
These ones concern MongoDB Oplog scaling in Meteor: