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: