MongoDB has no fixed schema, but that does not mean schema design does not matter — it means the decisions move from "which columns does this table have" to a different question: for any two related pieces of data, do you embed one inside the other, or keep them in separate collections and reference one from the other?
Embedding puts related data directly inside the parent document, as a nested object or array:
{
name: "Rahul Verma",
address: {
city: "Kolkata",
pincode: "700001"
}
}One query returns everything — no second lookup needed. Embedding fits data that is only ever read with its parent and does not grow without bound, like an address on a user, or line items on a specific order.
Referencing stores related data in its own collection, and the parent document holds just an _id pointing to it:
// In the "authors" collection
{ _id: "auth1", name: "Rahul Verma" }
// In the "posts" collection
{ title: "Getting Started with MongoDB", authorId: "auth1" }Referencing fits data that is reused across many parents (one author has many posts), grows without a practical limit (a popular post could have thousands of comments), or genuinely needs to be queried and updated on its own.
| Situation | Lean toward |
|---|---|
| Data only makes sense attached to its parent | Embedding |
| Data is reused by multiple parents | Referencing |
| The nested list could grow very large (thousands+) | Referencing |
| You always read the two together | Embedding |
| You need to query the child independently | Referencing |
Not an all-or-nothing choice
This decision is the MongoDB equivalent of SQL normalization — but decided per relationship, not applied uniformly. The same application very often embeds some relationships and references others.