What is the difference between embedding and referencing?

Question

Accepted Answer

**Embedding** stores related data *inside* a document (nested); **referencing** stores it in *separate* documents linked by id. This is the core modeling decision in MongoDB, with different trade-offs for read performance, data size, and update complexity.

## Embedding — nested within the document

```js
{
  _id: ObjectId("..."),
  title: "My Post",
  author: { name: "Ann", email: "ann@x.com" },   // EMBEDDED author
  comments: [                                      // EMBEDDED comments
    { user: "Bob", text: "Great!" },
    { user: "Carol", text: "Thanks" }
  ]
}
// ✓ ONE query gets the post + author + comments (fast, atomic)
// ✗ if author info changes, must update it in every post embedding it (duplication)
// ✗ document grows with comments → could hit the 16MB limit if unbounded
```

## Referencing — separate documents linked by id

```js
// posts collection
{ _id: ObjectId("p1"), title: "My Post", authorId: ObjectId("u1") }
// users collection
{ _id: ObjectId("u1"), name: "Ann", email: "ann@x.com" }
// comments collection
{ _id: ObjectId("c1"), postId: ObjectId("p1"), user: "Bob", text: "Great!" }

// ✓ author/comments stored ONCE, updated in one place; no document-size issues
// ✓ each entity managed independently
// ✗ need multiple queries or $lookup to combine (slower reads for related data)
```

## The trade-offs side by side

```text
                  Embedding                    Referencing
Reads             ✓ fast (one query)           ✗ multiple queries / $lookup
Data duplication  ✗ duplicated (update many)   ✓ stored once
Document size     ✗ grows (16MB limit risk)    ✓ no size concern
Updates           ✗ update in every copy       ✓ update in one place
Atomicity         ✓ atomic (single document)   ✗ across documents
Best for          contains, accessed-together  shared, large, independent, many
```

## A hybrid approach (common)

```js
// embed a SUBSET for fast reads, reference for the full data
{ title: "Post", author: { _id: ObjectId("u1"), name: "Ann" } }  // enough for display
// → reference (author._id) for full details when needed; embed name for the common read
```

## Why it matters

Understanding embedding vs referencing is the **core skill of MongoDB data modeling**, so it's essential knowledge for designing effective MongoDB applications.

This decision — storing related data inside a document (embedding) vs in separate linked documents (referencing) — directly determines an application's read performance, data consistency, document size, and update complexity, making it the most consequential MongoDB design choice.

Understanding the **trade-offs** is key: **embedding** gives fast single-query reads of related data and atomic updates (suiting "contains" relationships, together-accessed data, bounded sub-data) but causes duplication (update complexity if the data is shared) and document growth (risking the 16MB limit if unbounded); **referencing** stores data once (easy updates, no duplication, no size issues, independent management) but requires multiple queries or `$lookup` to combine (slower related-data reads).

Knowing which fits which scenario — embed for bounded, owned, together-accessed data; reference for large, shared, independent, or many relationships — is the essential modeling judgment.

Understanding the common **hybrid approach** (embedding a subset for fast reads while referencing for full data — getting the best of both) reflects sophisticated design.

Since this decision profoundly affects MongoDB application quality (wrong choices cause slow queries, bloated documents, or painful updates), and since it's the fundamental, distinctive MongoDB modeling skill (with no direct SQL equivalent — SQL normalizes by default), understanding embedding vs referencing — the trade-offs, when to use each, and hybrid approaches — is essential, high-value knowledge that's at the heart of effective MongoDB data modeling and one of the most important and frequently-discussed MongoDB topics, central to designing schemas that perform well for an application's access patterns.