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.

MongoDB Upgrades Stitch, Its New Backend-as-a-Service

MongoDB has recently upgraded its Backend as a Service version, MangoDB Stitch.

#news