Denormalization trade-offs in MongoDB - Step-by-Step Execution

Concept Flow - Denormalization trade-offs

Start: Data stored normalized

↓

Decision: Need faster reads?

No→Keep normalized

Yes↓

Denormalize: Embed or duplicate data

↓

Trade-offs: Faster reads but more storage and complex writes

↓

Monitor and adjust as needed

Shows the decision process of when to denormalize data in MongoDB, balancing read speed against storage and write complexity.

Execution Sample

MongoDB

db.orders.insertOne({
  _id: 1,
  customer: { _id: 123, name: "Alice" },
  items: ["apple", "banana"]
})

Inserts an order document embedding customer info to speed up reads but duplicates data.

Execution Table

Step	Action	Data State	Effect
1	Insert order with embedded customer	{ order: { _id:1, customer:{_id:123, name:"Alice"}, items:["apple","banana"] } }	Data duplicated if customer info exists elsewhere
2	Read order document	Same as inserted	Fast read, no join needed
3	Update customer name in orders	Must update all orders with customer _id 123	Write complexity increases
4	Add new order for same customer	Embed customer info again	Storage increases due to duplication
5	Decide to keep denormalized for read speed	Trade-off accepted	Faster reads at cost of storage and writes

💡 Trade-off decision made: faster reads prioritized over storage and write complexity

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	Final
orders collection	empty	[{_id:1, customer:{_id:123, name:"Alice"}, items:["apple","banana"]}]	[{_id:1, customer:{_id:123, name:"Alice Updated"}, items:["apple","banana"]}]	[{_id:1, customer:{_id:123, name:"Alice Updated"}, items:["apple","banana"]}, {_id:2, customer:{_id:123, name:"Alice Updated"}, items:["orange"]}]	2 documents with duplicated customer data

Key Moments - 2 Insights

Why does updating customer info become more complex after denormalization?

Because customer data is duplicated inside each order, every order with that customer must be updated, as shown in step 3 of the execution_table.

Does denormalization always save storage space?

No, denormalization duplicates data, increasing storage usage as seen in step 4 where a new order embeds the same customer info again.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what is the main benefit of reading the order document?

A Fast read with no need for joins

B Less storage used

C Simpler writes

D Customer data is normalized

💡 Hint

Refer to step 2's Effect column in the execution_table

At which step does write complexity increase due to denormalization?

A Step 1

B Step 3

C Step 4

D Step 5

💡 Hint

Check the Action and Effect columns at step 3 in the execution_table

If we removed embedding customer data in orders, how would the storage usage change?

A Storage would increase

B Storage would decrease

C Storage would stay the same

D Storage would become unpredictable

💡 Hint

Look at variable_tracker showing duplicated customer data increasing storage

Concept Snapshot

Denormalization trade-offs in MongoDB:
- Embed or duplicate data to speed up reads
- Increases storage due to duplication
- Makes writes more complex (updates must be done in multiple places)
- Useful when read speed is critical
- Requires monitoring to balance costs

Full Transcript

Denormalization in MongoDB means storing data duplicated or embedded to make reading faster. For example, embedding customer info inside orders avoids needing to join collections when reading. This speeds up reads but duplicates data, increasing storage. Also, when customer info changes, all orders with that customer must be updated, making writes more complex. The execution steps show inserting an order with embedded customer, reading it fast, updating customer info in all orders, adding new orders with duplicated data, and finally deciding to accept these trade-offs for faster reads. Beginners often get confused why writes become harder and storage grows after denormalization. The key is understanding that duplication helps reads but costs more storage and write effort. Monitoring and adjusting is important to keep balance.