"Use MongoDB!" said the first engineer. "No, use MySQL," said the second. And there you were, watching them fight like football fans supporting their favorite team—MongoDB vs MySQL.
Of course, you can't base technical decisions on feelings. You need to understand the upsides and downsides of each option and how they align with your company's needs.
This article is about the tools you need to make an informed decision about. And in order to do that, you need to understand that a straight comparison of MongoDB versus MySQL isn't a fair one. That's like comparing apples to oranges instead of apples to apples. Why? Because MongoDB is a noSQL database, and MySQL is a SQL database.
So before we get into the specifics of each product, we need to address the real question: should you use SQL or noSQL?
What are the differences between SQL and noSQL databases?
Both SQL and noSQL databases are tools designed to store information. The difference is how the information is organized internally.
A relational database is based on a relational model. In this model, data is heavily structured. You define a data model by putting together a set of tables that contain records with a fixed number of fields that contain a specific data type.
The database itself makes it easy for you to enforce consistency across the model via tools such as foreign keys.
In a relational database, foreign keys enable you to connect data from one table to another.
And having a strong system in place helps prevent some simple inconsistencies within the database.
A noSQL database doesn't use a relational model. There are no tables, records, or fields. Instead, noSQL databases have collections, documents, and properties.
Keep an eye on the field names. While a SQL database has consistent columns, a noSQL database may have different data associated with each record.
You might get the impression that this is another way of saying the same thing. But it's not. In a relational database, the information structure plays a major role. In a noSQL database, information is stored in a loose structure, so the properties of two different documents in the same collection can vary significantly.
Another important difference is that database engines don’t know the relationship between documents in different collections. That makes it harder to keep those relationships consistent (by avoiding orphans, for instance) and to retrieve related information spread across several collections.
The lack of these safety mechanisms give noSQL databases an edge over relational ones in terms of general performance and scalability. But the cost is the loss of certainty in the quality of the information.
Now that we have some clarity regarding noSQL databases and SQL databases, we can look at MongoDB vs MySQL.
What is MongoDB?
MongoDB is an open-source document-oriented database, also referred to as a noSQL database. As such, its direct competitors are CouchDB, Cassandra, and HyperTable.
One of the outstanding features of MongoDB is its performance. Most operations are optimized to use local RAM, so if the hardware is available and the indexes are properly designed, a MongoDB-based database can be a real asset. Another strong point is its thorough documentation.
The downside is that MongoDB's disk space administration could be better. So if you're planning on using it, be ready to set aside large disks for it.
What is MySQL?
MySQL is an open-source relational database engine. Its direct competitors are PostgreSQL and MariaDB.
One interesting feature is its ability to determine its storage strategy on a per-table basis, allowing for fine-tuning depending on the scenario.
MySQL is one of the fastest relational databases. It also offers some interesting features in terms of replication and sharding to improve scalability.
One of MySQL's greatest strengths is its widespread usage, especially in web development.
When should you use MongoDB over MySQL and vice versa?
There are two main factors that come into play when choosing between relational and noSQL databases: how static your data is and how plug-and-play the tool will be for your team.
How often data is updated
In general, a project with frequently updated data will benefit more from a relational database than a nonrelational one. An example of such a project would be any kind of transactional system, like an ecommerce platform, a workflow application, or a payment processor.
On the other hand, a project that rarely updates information, such as an analytics application where data doesn't change after it has been collected, will benefit more from a nonrelational database.
Ease of use
Another thing to keep in mind when making is your team's ability to work with either product. In this area, MySQL generally has an advantage over MongoDB.
As you probably know, SQL stands for Standard Query Language. Let me stress the word standard here. Because when you have an application designed to work with MySQL (or any other SQL-based database), the cost of migrating to a different product is minimal.
A query such as the following will be executed just fine in MySQL, PostgreSQL, SQLite, Oracle, and so on:
SELECT * FROM users WHERE username = 'mchojrin';
This means that even if your development team isn't proficient in MySQL itself but has experience working with another SQL database, chances are they'll get up to speed quickly.
On the other hand, if you want to perform a similar query using MongoDB, you'll have to issue a command like the following:
db.user.findOne({name: "mchojrin"});
That command will be very different if you choose CouchDB or any other noSQL database. And the same goes for other types of queries such as insert, update, delete, and so on.
So if you're considering switching databases on a project that's already in production, take a minute or two to decide whether the benefits you’ll get are worth the cost of rewriting important parts of the code.
How to decide
How should you decide between MongoDB vs MySQL? It all comes down to the question of what you need to prioritize: speed or confidence.
If your project's success depends on users getting answers to their queries in real-time, you should opt for a nonrelational database.
If, on the other hand, your biggest concern is having information you can trust no matter what, a relational database is your best option.
There is a third choice
In reality, though, there's a third choice that might not be obvious: you can use both! It's not necessarily a zero-sum game.
If you're smart about this, you can have the best of both worlds and use a relational database for your day-to-day transactional needs and a nonrelational database for your once-in-a-while processes.
And if you find yourself in a situation where you have several different data sources that need to be unified, you can use a tool such as Panoply that can give you the full picture. With Panoply you can easily bring together all your business data in a single place. You don't have to change your applications infrastructure or architecture, build complex APIs, or anything like that. To learn more about how easy Panoply is to use, book a personalized demo.
