beginnerintermediateadvanced

MongoDB · Embedding vs. Referencing

Embedding vs. Referencing

Cardinality strategies, the named schema design patterns, and denormalization as a deliberate choice

Cardinality narrows itboundedness, not the label, makes the final call
1:many → id on the childnot a growing id array on the parent
Six named patternseach solves one specific, measured symptom
Denormalize on purposea bounded trade, not the relational anti-pattern

1.Embed-when and reference-when signals

Three signals point to embedding: read together, bounded, naturally owned by the parent. Three signals point to referencing: grows independently, shared across many parents, has its own lifecycle. Most relationships show a clear majority one way.

Key features

Embed signals: read together with the parent, bounded in size, owned only by this parent
Reference signals: grows independently, shared across many parents, has its own lifecycle
A relationship rarely shows every signal on one side — weigh which signals matter most for this workload
When signals conflict, the more expensive failure mode (unbounded growth vs. an extra query) usually decides it

Command

text

// Embed signals: read-together + bounded + parent-owned
// Reference signals: independent-growth + shared + separate lifecycle

Embed: read together, bounded, parent-owned. Reference: independent growth, shared, own lifecycle. Weigh signals per relationship, not per document.

2.Modeling strategies by relationship cardinality

One-to-one usually embeds. One-to-many splits by growth: embed a bounded "few," reference an unbounded "many." Many-to-many always references, with an array of ids on one or both sides. Hierarchical data uses parent/child references or a materialized path.

Key features

One-to-one: usually embed — the child data always exists with, and only with, the parent
One-to-few (bounded one-to-many): embed, often as an array on the parent
One-to-many/one-to-squillions (unbounded): reference, usually a parent id stored on each child
Many-to-many: reference in both directions, or an array of ids on the more selective side
Hierarchical (trees): reference via parent pointers, or a materialized path field for subtree queries

Cardinality → default strategy

Cardinality → default strategy
Cardinality	Default strategy	Example
One-to-one	embed	a user and their single address
One-to-few	embed (bounded array)	a product and its size variants
One-to-many (unbounded)	reference — parent id on the child	a customer and their orders
Many-to-many	reference — array of ids on one/both sides	students and the courses they take
Hierarchical / tree	parent reference or materialized path	category tree, comment threads

Cardinality narrows the choice, it does not decide it

Bounded cardinality

one-to-one

embed

one-to-few

embed, bounded array

Unbounded / shared cardinality

one-to-many

reference, id on the child

many-to-many

reference, id array

hierarchical

parent ref or materialized path

Command

text

// One-to-many, referenced: put the "one" side's id on the "many" side's documents, not an array on the "one" side

One-to-one/few: embed. One-to-many (unbounded): reference, id on the child. Many-to-many: reference, id array on the more selective side. Trees: parent ref or materialized path.

3.The named schema design patterns, as a set

Six recurring solutions to common schema problems, each with a name: subset (trim a large document), bucket (group time-series data), extended reference (copy a few fields to avoid a $lookup), computed (precompute instead of recalculate), attribute (make similar fields queryable together), outlier (handle the rare huge document separately).

Key features

Subset: keep only the most-needed slice of a large sub-document embedded, reference the rest
Bucket: group many small time-series readings into fewer, larger per-interval documents
Extended reference: copy a few frequently-needed fields from a referenced document to avoid a $lookup
Computed: store a precomputed value (a total, a count) instead of recalculating it on every read
Attribute: move sparse, varying fields into a queryable name/value array instead of separate top-level fields
Outlier: model the rare oversized document as an exception, not the design the whole schema plans for

Command

text

// Each pattern targets one specific symptom — see section 8 for a worked example of each.

Six named patterns, each solving one specific symptom: subset (trim), bucket (group time-series), extended reference (avoid $lookup), computed (precompute), attribute (sparse fields), outlier (rare huge document). Apply on a measured symptom, not pre-emptively.

4.Denormalization as an intentional choice, not a shortcut

Duplicating a field (like copying a customer name onto every order) is normally an anti-pattern in relational design. In MongoDB, doing it on purpose — extended reference, computed values — is a documented trade of some duplication and write cost for far fewer joins and faster reads.

Key features

Denormalization here means storing a copy of data that also lives elsewhere, on purpose
It trades update simplicity (one source of truth) for read speed (no join needed)
It is justified when reads vastly outnumber writes to the duplicated field, or when staleness is acceptable
Every denormalized copy needs an explicit plan for how (or whether) it gets kept in sync
Not denormalizing by default: normalize first, denormalize where a measured read cost justifies it

Command

text

// Denormalize a specific field for a specific measured read cost — not "duplicate everything, everywhere"

Denormalize a specific, usually slow-changing field to remove a join from a measured hot read path — always with an explicit answer for how the copy stays (or is allowed to go) stale.

5.Schema design as a performance decision

A relational schema is judged mainly by correctness: does it avoid duplicate/inconsistent data? A MongoDB schema is judged mainly by performance: does it answer the app's real queries in as few reads as possible? Both must be correct; only one is primarily justified by fewer joins.

Key features

Relational design starts from entities and normal forms; MongoDB design starts from access patterns
A MongoDB schema is "correct" if it enforces the invariants that matter — not if it eliminates all duplication
The same entities can be modeled several different, all-valid ways depending on which queries matter most
Changing the dominant access pattern later is a real reason to reshape the schema, not a design failure
This is why data modeling is listed as a core senior MongoDB skill: the decision requires knowing the workload, not just the entities

Command

text

// The question is not "is this schema normalized" — it is "does this schema answer our real queries cheaply"

A MongoDB schema is judged by whether it answers the app's real access patterns cheaply — not by relational normal-form rules. The same entities validly model differently depending on which queries matter most.

Spotted a mistake on this page? Tell us.

Read Sheet