What is MongoDB?

Learn about MongoDB and what sets it apart from other non-relational and relational databases

TABLE OF CONTENTS
  1. MongoDB vs. Traditional Relational Databases
  2. Querying in MongoDB
  3. Pros of Using MongoDB
  4. Cons of Using MongoDB
  5. Should you use MongoDB for your next project?
Table of contents
Chapter 1
Chapter 2
Chapter 3
  1. MongoDB vs. Traditional Relational Databases
  2. Querying in MongoDB
  3. Pros of Using MongoDB
  4. Cons of Using MongoDB
  5. Should you use MongoDB for your next project?

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.

MongoDB vs. Traditional Relational Databases

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.

Querying in MongoDB

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:

  1. By specifying the exact fields you want to return (known as projection)
  2. Using Boolean expressions such as $and(), $or(), and $not() to join multiple   queries together

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.

Pros of using MongoDB

Data Structure Flexibility

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.

Speed

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.

Polyglot Persistence

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.

Cons of using MongoDB

Non-Structured Data Structure

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.

No Transactions

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.  

Schemaless Design

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).

Should you use MongoDB for your next project?

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.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
SECTIONS
  1. MongoDB vs. Traditional Relational Databases
  2. Querying in MongoDB
  3. Pros of Using MongoDB
  4. Cons of Using MongoDB
  5. Should you use MongoDB for your next project?