Busting the Top Myths About MongoDB vs Relational Databases

I was talking with a friend of mine recently about deciding between databases for an upcoming project. I asked him his thoughts on MongoDB. He told me that he did not think it would work based on what he knew about it. The only issue was that everything he learned about MongoDB was from 2013. He had not kept up with over a decade of improvements and updates. From talking with other developers this seems to be a pretty common situation. A lot of developers got a first impression of MongoDB in 2012-2014 and made up their minds based on that. In this post, we will dive into some database history and look at how MongoDB compares to relational databases today.

As a quick refresher, there are a number of types of databases, but we will be focusing on relational and NoSQL document databases since those are two of the most popular types in use today. Relational databases were introduced in the 1970s and store data in tables. While the term NoSQL was coined in 1998 by Carlo Strozzi, it took a few more years for NoSQL databases and their more flexible approach to storing data to really take off. In 2009 MongoDB launched with the idea of storing data in documents similar to JSON objects. When I am explaining the basic difference between relational and document databases to my family, I usually say one is like a spreadsheet and the other is like a Google Doc. I am still not sure how much my grandma understands about what my job is, but at least she knows the difference between database types now.

OK, now that we have covered the basics, we will take a look at misconceptions that come up when comparing MongoDB to relational databases.

Myth 1: MongoDB does not have a schema

Schemata define the structure of data in a database. With relational databases, you typically design your schema based on normalizing your data. Normalizing means you split up your data into different tables so that you do not duplicate data. These defined schemata are great if you can anticipate all your future data needs and elegantly design them in advance. Updating these schemata to add new fields can add extra work and downtime for your application.

With MongoDB, your schema is dependent on the needs of your application. This is a more flexible approach to schema design. Now even though there is flexibility, there are still best practices like the rule that “data that is accessed together should be stored together.”

Here is an example of the relational data from above stored in MongoDB:

{
    "first_name": "Paul",
    "surname": "Miller",
    "cell": "447557505611",
    "city": "London",
    "location": [45.123, 47.232],
    "profession": ["banking", "finance", "trader"],
    "cars": [
        {
            "model": "Bentley",
            "year": 1973
        },
        {
            "model": "Rolls Royce",
            "year": 1965
        }
    ]
}

You can see in this example that you are able to get all the data on “Paul Miller” without having to do JOINS on three different tables. You can do JOINS in MongoDB, but more on this later.

With a flexible schema, developers are able to start building applications without having to design beforehand the definitive schema, and then constraining themselves to it. You can easily add new fields to your schema whenever the application requires it. If you want to have that more structured schema, you can use MongoDB’s schema validation feature. If you need your schema to evolve over time, you can also easily implement the schema versioning pattern.

Ultimately I think this myth of MongoDB having no schema comes down to two things. First, it did not have schema validation in the early days (it was added in version 3.6 in 2017). The other reason comes from the flexibility developers have in creating their schema based on the needs of their applications. Freedom and flexibility does not mean not having a schema; it just means it is important to follow best practices to create an elegant schema that makes your application run optimally.

Myth 2: MongoDB is not ACID compliant

Databases need ways to make sure that operations and the resulting data are reliable even when errors or power failures occur. The main way they do this is by implementing four properties: atomicity, consistency, isolation, and durability, also known as ACID.

MongoDB is ACID compliant. Every time that you perform any create, read, update, and delete operation on a single document, data integrity is preserved. MongoDB handles data one document at a time. Otherwise, it would not be a document database. It would be a chaotic, unpredictable database. Can you imagine lots of writers trying to overwrite the same document at the same time? I have been in some Google docs with 10+ writers all contributing at the same time, and it certainly does not feel ACID compliant.

That covers single documents, but what happens with multidocument transactions? Multidocument transactions are used frequently in relational databases, since you often have to access multiple tables when doing things like updating a customer record. MongoDB guarantees multidocument ACID transactions from and to any location in your MongoDB cluster. It has supported this guarantee since version 4.0 back in 2018.

In fact, transactionality is one of MongoDB’s greatest strengths. Many financial services companies trust MongoDB transactions for core banking and trading use cases. The all-or-nothing guarantee of MongoDB multidocument transactions has got your back.

Myth 3: MongoDB cannot make JOINS to handle relational data

Earlier we showed how relational databases rely on data split across multiple tables for efficient schema design. To work with relational data, you often need to pull data from those tables and combine them using JOINS.

MongoDB can do JOINS with the $lookup command. But the fact that you can do something does not mean you should. MongoDB data is modeled in a different manner than relational data. In MongoDB, data that is accessed together is stored together. With most of the data in a single document instead of spread across multiple tables, you would not need to do any JOINS since the data is already in the right place. This shift from the relational model to the document model is a big mindset shift, but once you experience the benefits, it is hard to go back. However, if you still need to do JOINS with MongoDB, the command $lookup is your best ally. You can even create a VIEW (added in 2016) to join two collections.

The myth that JOINS are not possible ultimately comes down to the basic difference between the relational and document models. Data accessed in tables and data accessed in documents require different approaches, but generally, even though you can do JOINS in MongoDB, you will not need to if you have designed the schema for your documents well.