How do you design schemas in MongoDB?

Question

Accepted Answer

MongoDB schema design centers on a key decision: **embedding** (storing related data inside a document) vs **referencing** (storing related data in separate documents/collections with references). Unlike SQL's normalize-by-default, MongoDB design optimizes for how the data is *accessed*.

## Embedding — store related data together

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**Embedding** keeps related data in one document — read it all in a single query (fast, no joins). Good for data accessed together and "contains" relationships.

## Referencing — link separate documents

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**Referencing** stores data separately and links by id (like a foreign key) — query separately or join with `$lookup`.

## When to embed vs reference

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## Design for access patterns (the key principle)

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## Why it matters

Schema design is critically important in MongoDB — it's different from and arguably more consequential than in SQL, because MongoDB's flexible document model gives you choices that significantly affect performance and maintainability, so understanding it is essential for building effective MongoDB applications.

The central decision — **embedding vs referencing** — is the defining MongoDB design choice: **embedding** (storing related data within a document) enables fast single-query reads of related data (no joins) and suits data accessed together and "contains" relationships, while **referencing** (linking separate documents by id) suits large/unbounded data, independently-accessed data, and shared/many relationships.

Understanding **when to use each** (embed for bounded, together-accessed, owned data; reference for large/growing, independent, shared, or many relationships — and being mindful of MongoDB's 16MB document size limit) is the key skill.

Most importantly, understanding the guiding principle — **design for access patterns** (structure data around *how you query it*, so common queries are efficient, often a single document read, rather than normalizing by default like SQL) — is what distinguishes good MongoDB schema design.

This may mean accepting some **denormalization** (duplication) for read efficiency, a trade-off against update complexity that's acceptable and often correct in MongoDB.

Since schema design profoundly affects MongoDB application performance and maintainability (a poor embed/reference choice causes slow queries, huge documents, or update complexity), and since the access-pattern-driven, embed-vs-reference approach is fundamentally different from SQL normalization, understanding MongoDB schema design — the embed/reference decision, when to use each, and designing for access patterns — is essential, high-value knowledge for building effective MongoDB applications, one of the most important and distinctive MongoDB topics that separates those who design good document schemas from those who naively port relational designs.