When MongoDB came out six years ago, the NoSQL fad was in full swing. Rather than rely on a table-based relational database structure, MongoDB utilizes BSON, or “Binary JSON,” which many users found attractive; the platform quickly grew into a leader among NoSQL databases. As more people took the MongoDB plunge, however, many began to complain about various issues, including its lack of speed. For the past few years, people have debated whether that initial hype was worth it. Now that the technology’s reached maturity, and many of its most annoying bugs have been squashed, that question can be confronted head on: Is it worth using MongoDB when you can stick with an old, rugged SQL standby such as MySQL? Before we dig into the issue, let’s look at the purpose behind each technology:
- MySQL is for storing relational data
- MongoDB is for storing documents in JSON and BSON
I've seen a lot of developers favor a NoSQL solution such as MongoDB for the bulk of their work, because they assume that MySQL remains unable to accomplish certain tasks. "My data has a unique layout, that can’t be put into relational, tabular form," these people claim. But if you do some digging, you’ll often find that people are able to accomplish whatever they need with a relational database, provided they code carefully and don’t try to take shortcuts. The format is more versatile than many people will admit; for decades, people have created complex structures and stored them in relational databases just fine. Check out the latest database-related jobs. Developers also dislike certain aspects of MongoDB. It doesn’t allow joins, for example, which leads people to stuff in gigantic documents with lots of repeated data, creating a royal mess. Making things worse is MongoDB’s insistence on restricting access; if you’re adding customer orders to a giant document, other people can’t add rows until you’re finished. With MySQL, on the other hand, people in that situation could add orders simultaneously. (Those who insist on bringing joins-like functionality to MongoDB can put records in separate documents, although this can require some creative coding on the developer's part.) Even those companies and prominent developers who like MongoDB don't rely on it for every database-related issue. For example, some firms have a real problem with what they perceive as MongoDB’s lack of ACID compliance. If your project requires large amounts of normalized data, with loads of reads and writes, it’s probably best to go with MySQL, rather than “trying to make it work” in MongoDB. As with any popular software platform, both MongoDB and MySQL suffer from perception issues, some of which are, frankly, unfair. People claim that MySQL doesn’t easily scale horizontally, and that the only option for doing so is to increase memory on a single MySQL server. That’s an outmoded claim; there are plenty of ways to scale. In a similar fashion, a lot of people insist that MongoDB will crash and cause massive data loss; while that was an issue in the past, developers have squashed many of the related bugs. So is it worth using MongoDB over MySQL? Not in every situation. When deciding which is better suited to your project, spend time studying the documentation for both, and try working with a dataset in MongoDB to see whether it fits your needs. Understand the role that benchmarks play: For instance, if you're building a website that does a handful of database queries per second, does it matter which database can perform a couple thousand per second? Bottlenecks can have a huge impact on application performance; it pays to read up on how to optimize your implementation, regardless of which one you choose. I’ve been engaged in SQL programming since around 1990. When I found MongoDB, it was like a godsend, as it allowed me to store complex structures easily. Over time, however, I realized I was relying on MongoDB as a sort of a crutch, and moved back to MySQL. Today, I use MongoDB when I need document storage that doesn’t require continual tweaks of small fields, but I generally use MySQL for most of my work. But my situation doesn't apply to everyone: Explore both, learn them well, and you'll find what works best for your needs.
