Contact

MongoDB Embed vs. Reference: Data Modeling Explained

Video

MongoDB helps developers build and scale applications with flexible, document-based data — but knowing how to structure that data is its own puzzle. For their "Lightbulb Moments" video series, MongoDB tapped Lemonly to break down one of the trickiest early decisions in database design: whether to embed data or use references.

The result is a snackable explainer that turns a technical concept into something anyone can digest — literally. Using pizza as our guide, we show how embedding is like grabbing a pre-made pie (fast, convenient, all-in-one) while referencing is like keeping your dough, sauce, and toppings in separate containers (more flexible, but more steps). The video walks through the trade-offs of each approach and lands on a simple rule of thumb: Data that's accessed together should be stored together.

The real challenge was making an abstract, developer-level concept click for technical and nontechnical viewers alike — without dumbing it down. By leaning into a metaphor everyone already understands (who doesn't have feelings about pizza toppings?), we gave MongoDB a lightbulb moment that's as clever as it is clear.

When it’s time to set up your data in MongoDB, you have an important decision to make: Should you embed your data in documents or use references?

Think of it like preparing a pizza: You can either heat one up from a box or make your own with custom toppings.

Embedding data is your pre-made pizza — fast, convenient, and served as a single unit. It’s a great strategy for when you always need to access the same data together.

MongoDB’s secondary indexes are like the words on the box; they help you find “pizzas without ham” or “pizzas with pineapple,” if you’re into that sort of thing. But when you grab your box, you’re grabbing the whole thing — you can’t take just the pepperoni and leave the cheese behind. In the same way, querying an embedded document means you retrieve all the embedded data, even if you only need part of it.

When you want only a subset of data, it’s best to keep things separate. That’s when creating references comes in handy. Your references are like different ingredients stored in different containers. You can keep your dough, sauce, cheese, and toppings on their own and update or swap a single ingredient without touching the others.

The trade-off? Making each pizza takes longer. Instead of grabbing one box, you’re visiting multiple containers for your dough, cheese, and toppings. In database terms, that means you need multiple queries to fetch all your related data.

So, how do you know when to embed or reference? Always remember: Data that is accessed together should be stored together. Embed when data is naturally consumed as a whole, and reference when you want the flexibility to mix and match. You can do it all with MongoDB.

Other work in this series