Embedded Documents, Arrays, and Nested Data Modeling
Learn one of MongoDB’s greatest strengths: storing related data together in document-shaped structures.
Inside this chapter
- Why Embedded Modeling Matters
- Example Embedded Order Document
- When Embedding Works Well
- When Embedding Becomes a Problem
Series navigation
Study the chapters in order for the clearest path from MongoDB basics to advanced document modeling and production operations. Use the navigation at the bottom of each page to move through the full series.
Why Embedded Modeling Matters
MongoDB shines when related data belongs together and is often read together. Instead of splitting everything into separate relational tables, teams can embed subdocuments and arrays inside a parent document for simpler reads and more application-friendly structure.
Example Embedded Order Document
{
orderId: "O1001",
customerId: "C1001",
orderStatus: "PENDING",
items: [
{ sku: "BK-101", productName: "Database Guide", qty: 1, price: 799 },
{ sku: "KB-220", productName: "Wireless Keyboard", qty: 1, price: 2499 }
],
shippingAddress: {
city: "Pune",
postalCode: "411001"
}
}When Embedding Works Well
- Data is usually accessed together
- Subdocuments are not excessively large
- Independent updates are limited or manageable
- The parent document remains within healthy size limits
When Embedding Becomes a Problem
If one substructure grows without bound, changes independently at high frequency, or is shared across many other documents, embedding can become less suitable. Strong MongoDB design means knowing where embedding helps and where it creates future pain.