MongoDB Introduction

MongoDB is a database that stores data as documents: flexible records that look like JSON objects. Shopping sites, food delivery apps, games and content platforms use it to keep product catalogues, user profiles, orders and chat messages. If you can read a JavaScript object, you can already read a MongoDB document.

In this lesson you will learn what MongoDB is, how its document model compares with the tables you may know from SQL, and how to decide when MongoDB is a good fit for a project.

What is MongoDB?

MongoDB is a document database, one of the family of databases called NoSQL ("not only SQL"). Instead of splitting data into rows and columns, it keeps each record as one document made of fields (names) and values. A value can be text, a number, a date, a list or even another document.

Here is a product from an online shop, written as a MongoDB document:

{
  "_id": 105,
  "name": "Bluetooth Earbuds",
  "category": "Audio",
  "price": 2499,
  "stock": 60,
  "tags": ["wireless", "mobile", "music"]
}

Every document has an _id field that identifies it uniquely, like a primary key. The tags field holds a list, called an array. In a SQL database you would need a second table for those tags; in MongoDB they simply live inside the product.

Documents that describe the same kind of thing are grouped in a collection, and collections are grouped in a database. MongoDB actually stores documents in a binary form of JSON called BSON, which adds extra types such as dates and exact decimals. You will study BSON in BSON Data Types & ObjectId.

Documents compared with SQL tables

Think of an order with two items. A relational (SQL) database usually spreads it over three tables and joins them back together when you read it:

SELECT o.id, o.order_date, c.name, i.product_name, i.qty, i.price
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN order_items i ON i.order_id = o.id
WHERE o.id = 1001;

In MongoDB the same order is usually one document, and the items are stored inside it:

{
  "_id": 1001,
  "customerId": 1,
  "status": "delivered",
  "items": [
    { "productId": 101, "name": "Wireless Mouse", "price": 799, "qty": 1 },
    { "productId": 104, "name": "USB-C Cable", "price": 299, "qty": 2 }
  ],
  "total": 1397
}

One read returns the whole order with no join, and the shape of the data matches the object your application code already uses. That is the main idea behind document databases: data that is used together is stored together.

The words change a little between the two worlds:

How you talk to MongoDB

MongoDB does not use SQL. You send commands written in the MongoDB Query Language (MQL), where a query is itself a document. In the MongoDB Shell (mongosh), finding cheap products looks like this:

db.products.find({ price: { $lt: 1000 } }, { name: 1, price: 1, _id: 0 })

[
  { name: 'Wireless Mouse', price: 799 },
  { name: 'USB-C Cable', price: 299 },
  { name: 'Learn Python Book', price: 649 }
]

Read it as "in the products collection, find documents whose price is less than 1000, and show only name and price". The $lt operator means "less than". You will run this yourself once you have built the practice data in The Practice Shop Database.

Applications use an official driver for their language, such as the Node.js, Python, Java or PHP driver. The queries look almost the same in every language because they are all built from documents.

Ways to run MongoDB

• MongoDB Community Server is the free edition you install on your own computer or server.
• MongoDB Atlas is MongoDB's cloud service. It runs the database for you on AWS, Google Cloud or Microsoft Azure and has a free tier that is enough for learning.
• MongoDB Enterprise Advanced is the paid self-managed edition with extra security and management tools for companies.

This course teaches MongoDB 9.0, released in September 2026. Almost everything also works on MongoDB 8.0 and 7.0, which many companies still run; lessons point out features that need a newer version.

When to use MongoDB

MongoDB is a strong choice when:

• Records vary in shape. A shop that sells phones, books and shoes needs different details for each. Documents in one collection can have different fields.
• Data is read as a whole object. Orders, blog posts with comments, user profiles with settings: embedding keeps related data in one read.
• The application is written in JavaScript or another object-based language. Documents map directly to objects, with no translation layer.
• You expect a lot of data or traffic. MongoDB can spread a collection across many servers, called sharding, and keeps copies on several servers for safety, called replication.
• You need search or AI features. MongoDB has full-text search and vector search for similarity and AI applications built in.

A relational database such as MySQL or PostgreSQL may suit you better when:

• The data is highly connected, with many many-to-many relationships that you join in different ways for every report.
• You need strict, fixed structure enforced on every row and the structure rarely changes.
• Your team and tools are already built around SQL reporting.

Common mistakes

• Copying SQL tables one to one. Creating a separate collection for every SQL table and joining everything throws away MongoDB's main strength. Design documents around how the application reads data.
• Treating "flexible" as "anything goes". If every document has different field names for the same thing (city, City, town), queries become unreliable. Agree on field names and use validation.
• Choosing a database because it is popular. Pick MongoDB because your data and access patterns fit documents, not because of trends.

Key points

• MongoDB is a document database: each record is a JSON-like document of fields and values.
• Documents live in collections, and collections live in databases; every document has a unique _id.
• Related data that is read together, such as an order and its items, is usually stored in one document.
• You query MongoDB with MQL, where queries are documents, from mongosh or a language driver.
• MongoDB runs on your own machine (Community Server) or in the cloud (Atlas, with a free tier).
• It fits varied, object-shaped data and large scale; a SQL database may fit highly relational, join-heavy data better.

{
  "_id": 1,
  "trainNumber": "12104",
  "from": "Lucknow",
  "to": "Pune",
  "journeyDate": "2026-12-20",
  "fare": 2340,
  "passengers": [
    { "name": "Rohan Gupta", "age": 29 },
    { "name": "Isha Verma", "age": 27 }
  ]
}