MongoDB is a document-oriented (aka non-relational) database. It's different than traditional relational databases like PostgreSQL, MySQL, or SQL Server because it stores data in JSON-like documents instead of tables. We'll go through the basics of MongoDB, how it differs from other databases, why businesses choose Mongo over alternative choices, and how Mongo benefits developers.
Let's start by covering the basics of how MongoDB stores your data. Traditional relational databases store data using tables and rows. MongoDB, on the other hand, is a non-relational (e.g. NoSQL) database with collections instead of tables. Documents are stored inside of collections in Mongo, whereas rows are stored in tables in traditional relational databases.
Here's an example of a document stored in MongoDB:
{ "first_name": "John",
"last_name": "Doe",
"address": {
"street": "123 Main St",
"city": "San Francisco",
"state_province": "CA",
},
}}
This same table, if stored in a traditional relational database table, would look like this:
First | Last | Street Address | City | State
John | Doe | 123 Main St | San Francisco | CA
With MongoDB, the structure and schema of your data is flexible and not enforced by a predefined table definition — unlike relational databases. Documents can vary greatly in size and shape within the same collection, whereas tables are more rigidly defined in relational databases.
Another key difference between MongoDB and traditional relational databases is that with MongoDB, you do not have to specify a schema upfront. This means no time spent on tedious table creation or tweaking of column definitions after your data starts to accumulate. Instead, mongo will add new fields to the document if mongo detects that they are missing. If you need a field in your mongo database, simply start adding it and mongo will take care of the rest.
Because MongoDB does not store data in a structured table format, you cannot query it using SQL. Instead, Mongo uses a more flexible and dynamic query language called mongo-specific queries.
With mongo-specific queries, you can run queries on your documents in various ways:
To perform a mongo-specific query, you must specify the collection name and your mongo query. Here's an example of querying all the customers whose name starts with "John" from our mongo database:
db.Customers.find({first_name:"John"})
In this example, we use mongo-specific queries to find all the documents where first_name is "John". Mongo will return an array of customer objects with only the first_name field populated. The response that gets returned will look like this:
[ {
first_name: "John",
}, ]
This is called a mongo array, which is similar to an SQL result set. In some Mongo databases like mLab, the mongo response will be automatically formatted for you and returned as a table with each field name mapped to its respective value.
MongoDB also provides powerful querying capabilities via find() , aggregate() , and mapReduce() functions (and their similarly named JavaScript counterparts). These functions return more succinct results of your mongo query than mongo-specific queries, allowing you to control the fields returned and use Boolean operators.
If you're looking for a simpler way to query data from MongoDB, check out our guide to importing MongoDB data to Google Sheets.
Mongo lets you store data in a flexible JSON document structure that can be customized based on your project needs. This is particularly helpful if you are starting a project and do not know what data you will eventually need to store, and exactly how you will use it down the line.
Mongo is lightning fast thanks to its ability to shard and replicate across multiple servers easily. This allows it to scale horizontally with very little effort on the developer's part. In order to scale horizontally on a relational database, you would have to shard your tables (e.g. break a table into multiple tables), which is a time-consuming process and more work than just replicating Mongo across multiple servers.
MongoDB can be used in conjunction with other data stores like MySQL and Elasticsearch via Mongoskin . This allows you to leverage Mongo's strengths, such as data structure versatility and quickness, while still taking advantage of the best elements of relational tables and SQL queries for complex data searches.
Mongo documents are not organized in a structured table format like traditional relational databases, which means Mongo cannot be easily indexed and searched. Complex queries on Mongo are also slower than comparable ones done on relational databases.
Transactions are critical in relational databases, where numerous data changes must be applied as a single unit to avoid corrupting the database. MongoDB does not support transactions natively, although Mongo-specific queries allow you to simulate this behavior. Mongo developers need to rely on other methods like Mongoskin for transaction management. This makes Mongo less reliable for data-sensitive applications where multiple users update the same record at once.
Mongo does not require you to define the structure of your data before inserting it. While this is beneficial if you don't yet know what form your data will take, it also means there can be a lot more guessing when using Mongo queries, and unexpected results may occur due to the lack of pre-defined schema (although MongoID offers some relief in this area).
Mongo is a great fit for projects that involve heavy amounts of non-structured data, such as models and documents. It's also well suited to applications where your database will be used by many different types of systems or devices. Some examples of these include IoT, media streaming apps like Netflix and YouTube, geospatial data for trucks or drones, medical applications (and research), financial transactions at banks etc.
On the other hand, Mongo is not as reliable for data-sensitive applications where multiple users update the same record at once. Mongo is not a good fit for applications where data must be structured in advance, and it should also be avoided if you need to run complex SQL queries on your database, since Mongo specific queries are not as robust as SQL. If you are building a sales management system or CRM, we recommend sticking with a relational database like MySQL.
