Embedding vs referencing decision in MongoDB - Visual Side-by-Side Comparison

Concept Flow - Embedding vs referencing decision

Start: Need to model related data

↓

Decide: Embed or Reference?

↓

Embed if data is

↓

small, tightly

↓

related, rarely

↓

changed together

↓

Implement chosen data model

↓

Query and update data accordingly

This flow shows how to decide between embedding or referencing data in MongoDB based on data size, relation, and update frequency.

Execution Sample

MongoDB

db.users.insertOne({
  name: "Alice",
  address: { city: "NY", zip: "10001" }
})

// vs

db.users.insertOne({ name: "Bob", address_id: ObjectId("abc123") })
db.addresses.insertOne({ _id: ObjectId("abc123"), city: "LA", zip: "90001" })

Shows embedding address inside user vs referencing address by ID.

Execution Table

Step	Action	Data Model	Data Stored	Query Impact
1	Insert user with embedded address	Embedding	{name: 'Alice', address: {city: 'NY', zip: '10001'}}	Single query to get user and address
2	Insert user with referenced address	Referencing	{name: 'Bob', address_id: ObjectId('abc123')}, {_id: ObjectId('abc123'), city: 'LA', zip: '90001'}	Two queries or $lookup needed to get full data
3	Update embedded address city	Embedding	Update user document directly	Simple update, no joins
4	Update referenced address city	Referencing	Update address document separately	Separate update, user document unchanged
5	Query user with embedded address	Embedding	One document returned with all data	Fast, no joins
6	Query user with referenced address	Referencing	User document returned, address fetched separately	Slower, needs join or multiple queries
7	Exit	Decision ends	Choose embedding for small, tightly coupled data Choose referencing for large, shared, or frequently changing data	Decision based on data characteristics

💡 Decision stops after evaluating data size, relation, and update patterns

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
User Document	{}	{name: 'Alice', address: {city: 'NY', zip: '10001'}}	{name: 'Alice', address: {city: 'NY', zip: '10001'}}	{name: 'Alice', address: {city: 'NY', zip: '10001'}}	{name: 'Alice', address: {city: 'NY', zip: '10001'}}	Embedded address inside user
Address Document	{}	N/A	N/A	N/A	{_id: ObjectId('abc123'), city: 'LA', zip: '90001'}	{_id: ObjectId('abc123'), city: 'LA', zip: '90001'}
User Document with Reference	{}	N/A	{name: 'Bob', address_id: ObjectId('abc123')}	{name: 'Bob', address_id: ObjectId('abc123')}	{name: 'Bob', address_id: ObjectId('abc123')}	User references address by ID

Key Moments - 3 Insights

Why do we embed data sometimes instead of referencing?

Embedding is chosen when related data is small, changes together, and is accessed together, so one document holds all needed info (see execution_table rows 1, 5).

When is referencing better than embedding?

Referencing is better when related data is large, shared by many documents, or changes independently, requiring separate updates (see execution_table rows 2, 4, 6).

Does embedding always mean faster queries?

Usually yes, because all data is in one document (row 5), but if embedded data grows too large, it can slow writes or exceed document size limits.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the user document updated directly with address data?

A Step 3

B Step 2

C Step 4

D Step 6

💡 Hint

Check the 'Action' and 'Data Model' columns for direct updates to embedded data.

According to variable_tracker, what does the user document contain after Step 2?

A Embedded address object

B Empty document

C Reference to address by ID

D Separate address document

💡 Hint

Look at 'User Document with Reference' row after Step 2.

If the address data changes frequently and is shared by many users, which data model is better according to the execution flow?

A Embedding

B Referencing

C Neither

D Both equally

💡 Hint

Refer to concept_flow and key_moments about data change frequency and sharing.

Concept Snapshot

Embedding vs Referencing in MongoDB:
- Embed when related data is small, accessed and updated together.
- Reference when data is large, shared, or changes independently.
- Embedding stores data in one document; referencing uses IDs to link documents.
- Embedding simplifies queries; referencing supports data reuse and separate updates.
- Choose based on data size, relation, and update patterns.

Full Transcript

This visual execution shows how to decide between embedding and referencing data in MongoDB. First, you consider if the related data is small and tightly connected, or large and loosely connected. Embedding means putting related data inside one document, which makes queries faster and updates simpler when data changes together. Referencing means storing related data in separate documents and linking them by IDs, which is better when data is large, shared by many, or changes independently. The execution table traces inserting users with embedded or referenced addresses, updating them, and querying them. The variable tracker shows how user and address documents change step by step. Key moments clarify why embedding is chosen for small, tightly coupled data and referencing for large, shared data. The quiz tests understanding of these steps and decisions. The quick snapshot summarizes when to embed or reference and their effects on queries and updates.