MongoDB schema design: embed or reference?

You fetch related data with a second query or with the aggregation $lookup stage:

db.customers.aggregate([
  { $match: { _id: 1 } },
  {
    $lookup: {
      from: "orders",
      localField: "_id",
      foreignField: "customerId",
      as: "orders"
    }
  }
]);

Rules of thumb

The key question is: "What does the application read together?" Data that is read together should usually be stored together.

Avoid unbounded arrays

This looks convenient but will eventually hurt:

// ❌ Every new order grows the customer document forever
{ _id: 1, name: "Ada", orders: [ /* thousands of orders */ ] }

Store orders in their own collection with a customerId field and an index, as above.

Extended references

A useful middle ground: reference the related document but copy the few fields you display most often:

{
  _id: 5001,
  customer: { id: 1, name: "Ada Lovelace" },  // copied for display
  items: [{ sku: "DB-101", qty: 2 }]
}

You avoid a lookup on the hot path, at the cost of updating the copy if the customer's name changes — acceptable for fields that rarely change.

Validate your schema anyway

Flexible doesn't mean schemaless. Use JSON Schema validation to guard the shape of your documents:

db.createCollection("orders", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["customerId", "items", "createdAt"],
      properties: {
        customerId: { bsonType: ["int", "long"] },
        items: { bsonType: "array", minItems: 1 },
        createdAt: { bsonType: "date" }
      }
    }
  }
});

Key takeaways

1. Model around your application's read patterns.
2. Embed one-to-one and one-to-few relationships.
3. Reference unbounded one-to-many and many-to-many relationships.
4. Copy a few stable fields to avoid lookups on hot paths, and validate your documents.

When should I embed documents vs use references in MongoDB?

Twelve common MongoDB relationships, from user addresses to org charts, each with an embed, reference or hybrid verdict, the document shape and the reason.

#data-modeling#nosql#schema-design