Data Modeling: embed vs reference

Two ways to relate data

Relational databases split everything into tables and join them. MongoDB gives you a choice for related data:

• Embed – nest the related data inside the parent document.
• Reference – store the related document separately and keep its _id in the parent (a manual join).

Embedding

Best when the related data is owned by the parent and read together – like a blog post and its comments, or an order and its line items:

{
  "_id": 1,
  "title": "My First Post",
  "comments": [
    { "user": "Ada", "text": "Great!" },
    { "user": "Alan", "text": "Thanks" }
  ]
}

One read returns the post and all its comments – fast, no join. The trade-off: documents have a 16 MB limit, so unbounded lists (millions of comments) should not be embedded.

Referencing

Best when data is large, shared, or grows without bound – like users and their thousands of orders:

// users collection
{ "_id": 1, "name": "Ada" }
// orders collection
{ "_id": 100, "userId": 1, "amount": 2500 }

You fetch the orders for a user with a query on userId, or combine them with a $lookup stage in aggregation.

Rules of thumb

• “Data that is read together should be stored together” – favour embedding for that case.
• Embed one-to-few; reference one-to-many or many-to-many.
• Reference when the related data is large, shared across parents, or unbounded.
• Model for your queries: design documents around how the app reads them, not around normalization.

Key points

• Embed related data that is owned by and read with the parent (post + comments).
• Reference data that is large, shared or grows without bound (user + orders).
• Watch the 16 MB document limit – do not embed unbounded arrays.
• Design documents around your read patterns, not around SQL-style normalization.