How do documents, collections, and databases relate to each other in MongoDB?

Updated Feb 20, 2026

Short answer

In MongoDB, documents are the individual records, collections group related documents, and databases contain collections. A database is the largest container: it holds collections, and collections hold flexible JSON-like documents.

Deep explanation

The hierarchy: database → collection → document

MongoDB organizes data in a simple hierarchy:

TEXT

Database
 └── Collection
      └── Document

A document is the basic unit of data stored in MongoDB. It is similar to a row in a relational database, but it can contain nested objects and arrays. Documents are stored in BSON (Binary JSON), which extends JSON with additional data types such as dates and binary data.

A collection is a group of related documents. It is similar to a table in SQL databases, but MongoDB collections do not require every document to have exactly the same structure.

A database is a container for collections. An application may use separate databases for different environments or products, such as development, testing, and production.

Rendering diagram…

How they work together

Imagine an e-commerce application:

The database might be called shop.
A collection might be called products.
Each product entry is a document inside that collection.

A document could look like this:

JSON

1{
2  "_id": "101",
3  "name": "Laptop",
4  "price": 900,
5  "tags": ["electronics", "computer"],
6  "seller": {
7    "name": "Tech Store",
8    "rating": 4.8
9  }
10}

Unlike a relational database row, this document can naturally store related information, such as the seller object and product tags, without requiring multiple joins.

MongoDB compared with SQL databases

MongoDB	Relational Database
Database contains collections	Database contains tables
Collection contains documents	Table contains rows
Document contains fields	Row contains columns
Flexible document structure	Fixed schema structure

The key difference is that MongoDB stores related data together as documents when that matches the application's access patterns. Developers decide whether to embed data inside documents or reference data across collections.

Embedding vs referencing

MongoDB supports two common ways to model relationships:

Embedding: Store related data inside one document. This is useful when data is usually read together.
Referencing: Store related data separately and connect documents using identifiers. This is useful when data is large, shared, or frequently updated independently.

For example, a blog post might embed comments if there are only a few comments. A large social platform might store comments separately because millions of comments should not live inside one document.

Rule of thumb: design MongoDB documents around how your application reads and writes data, not just around how the data is naturally related.

Why this matters in interviews

Interviewers want to know that you understand MongoDB is not just "SQL tables with different names." Collections and documents give MongoDB flexibility, but good schema design still requires thinking about query patterns, document size, update frequency, and relationships.

Real-world example

A food delivery app could use a database called foodDelivery. Inside it, there may be collections like restaurants, customers, and orders.

An order document might keep the customer's delivery address embedded because the address used for that order should remain unchanged even if the customer updates their profile later.

JavaScript

1db.orders.insertOne({
2  orderId: "5001",
3  customerId: "42",
4  items: [
5    { name: "Pizza", quantity: 2 }
6  ],
7  deliveryAddress: {
8    city: "Lucknow",
9    area: "Gomti Nagar"
10  }
11})

Here, foodDelivery is the database, orders is the collection, and each inserted object is a document. The structure is optimized for retrieving an order and all important details together.

Common mistakes

* **Confusing collections with databases** - A collection is inside a database
it is not a separate database. Use the hierarchy correctly.
* **Expecting identical documents** - MongoDB allows flexible schemas, but consistent design still improves maintainability.
* **Ignoring document size limits** - Avoid storing unlimited nested data in one document
split large or growing data into separate collections.
* **Using references everywhere** - Do not copy relational design blindly
embed data when it improves common queries.
* **Treating MongoDB like SQL** - Think about application access patterns instead of only normalizing data.

Follow-up questions

How is a MongoDB document different from a SQL row?
When should you embed documents instead of using references?
Can a MongoDB collection contain documents with different structures?
What is the role of the _id field in MongoDB documents?