References vs Embedding

Introduction

References vs embedding is the single most consequential decision in MongoDB modeling. Get it right, your app flies. Get it wrong, you'll do JavaScript joins forever or hit the 16 MB document limit.

Understanding the topic

Quick decision matrix:

• 1:1 — embed.
• 1:few (≤ 100) — embed.
• 1:many (unbounded) — reference.
• many:many — reference both sides, or junction collection.
• High write contention on child — reference.

Syntax reference

// Embed (1:few)
{ _id: 1, post: "...", comments: [ { author, text } ] }

// Reference (1:many)
// posts: { _id, title }
// comments: { _id, postId, author, text }
// Join with $lookup or two reads

Real-world use

Twitter-style apps reference tweets ↔ users. Order systems embed line items. Same database, two patterns — chosen per relationship.

Best practices

• Default to embedding; reach for references when ownership weakens.
• Use $lookup for references at query time.

Common mistakes

• Forcing SQL-style normalization on every collection — you'll lose every performance benefit.