MongoDB doesn't have foreign keys or native JOIN syntax like relational databases, but it still needs ways to represent connections between data — a customer and their orders, a post and its comments, an employee and their manager. This tutorial covers every relationship style available, from embedding to $graphLookup, and when to reach for each one.

📖 1. Introduction

Relationships in MongoDB come down to a single fundamental choice: should related data live inside the same document, or in a separate document connected by a reference? Every technique in this tutorial is a variation on that theme.

🧠 2. Understanding Relationships

Choosing a relationship style depends on three questions: how often the related data is accessed together, how large the related data grows, and whether it needs to be queried independently.

📦 3. Embedded Relationships

Embedding nests related data directly inside the parent document, allowing it to be fetched in a single read with no join required.

{
  _id: ObjectId("..."),
  name: "Alice",
  billingAddress: {
    street: "12 MG Road",
    city: "Chennai",
    zip: "600001"
  }
}

🔗 4. Referenced Relationships

Referencing stores a related document's _id instead of its full contents, requiring a separate query or $lookup to resolve it.

// orders collection
{
  _id: ObjectId("o1"),
  customerId: ObjectId("c1"),
  amount: 59.99
}

1️⃣↔️1️⃣ 5. One-to-One Relationships

Best modeled by embedding in most cases, unless the related data is large or infrequently accessed — for example, a rarely viewed user preferences document.

// Referenced alternative for large or rarely accessed data
// users collection
{ _id: ObjectId("u1"), name: "Alice" }

// user_preferences collection
{ _id: ObjectId("p1"), userId: ObjectId("u1"), theme: "dark", notifications: {} }

1️⃣↔️🔢 6. One-to-Many Relationships

The classic MongoDB modeling decision. A blog post with a handful of tags embeds well; a customer with thousands of orders does not.

// Embedded: small, bounded child list
{ title: "MongoDB Basics", tags: ["database", "nosql", "tutorial"] }

// Referenced: large, unbounded child list
// orders collection, referencing customer
{ _id: ObjectId("o1"), customerId: ObjectId("c1"), amount: 59.99 }

🔢↔️🔢 7. Many-to-Many Relationships

Typically modeled with arrays of references on one or both sides, depending on which direction is queried more often.

// students collection
{ _id: ObjectId("s1"), name: "Alice", courseIds: [ObjectId("c1"), ObjectId("c2")] }

// courses collection
{ _id: ObjectId("c1"), title: "Intro to MongoDB", studentIds: [ObjectId("s1")] }

♻️ 8. Self-Referencing Relationships

A document can reference another document in the same collection, commonly used for hierarchies like categories or organizational charts.

// categories collection
{ _id: ObjectId("cat1"), name: "Electronics", parentId: null }
{ _id: ObjectId("cat2"), name: "Laptops", parentId: ObjectId("cat1") }

👪 9. Parent-Child Relationships

A common self-referencing pattern where each document stores a pointer to its parent, forming a tree structure such as an employee reporting hierarchy.

// employees collection
{ _id: ObjectId("e1"), name: "Priya", title: "CTO", managerId: null }
{ _id: ObjectId("e2"), name: "Arjun", title: "Engineer", managerId: ObjectId("e1") }

📑 10. Data Duplication

Referenced relationships sometimes benefit from duplicating a small, rarely changing piece of related data to avoid an extra lookup on every read.

{
  _id: ObjectId("o1"),
  customerId: ObjectId("c1"),
  customerName: "Alice", // duplicated for fast display without a $lookup
  amount: 59.99
}

🔖 11. Document Linking

The simplest linking mechanism is storing the related document's _id in a field, then querying for it directly when needed.

const customer = await customers.findOne({ _id: order.customerId });

✍️ 12. Manual References

A manual reference is simply an _id value stored in another document — no special BSON type required. This is the recommended approach for the vast majority of relationships.

{
  _id: ObjectId("o1"),
  customerId: ObjectId("c1") // plain manual reference
}

📎 13. DBRefs

DBRefs are a legacy convention that embeds the collection name alongside the referenced _id, mainly useful when a field might reference documents from multiple collections.

{
  _id: ObjectId("comment1"),
  attachedTo: { $ref: "posts", $id: ObjectId("p1") }
}

🔗 14. $lookup

The $lookup aggregation stage performs a left outer join against another collection in the same database, resolving references into embedded arrays.

await orders.aggregate([
  {
    $lookup: {
      from: "customers",
      localField: "customerId",
      foreignField: "_id",
      as: "customer"
    }
  },
  { $unwind: "$customer" }
]).toArray();

🌳 15. $graphLookup

Performs a recursive search through a collection, following a chain of references — perfect for hierarchies like organizational charts or category trees.

await employees.aggregate([
  { $match: { name: "Arjun" } },
  {
    $graphLookup: {
      from: "employees",
      startWith: "$managerId",
      connectFromField: "managerId",
      connectToField: "_id",
      as: "managementChain"
    }
  }
]).toArray();

🧭 16. Join Strategies

🪆 17. Nested Relationships

Relationships can be nested several levels deep — an order references a customer, who references a loyalty tier, and so on. Each level adds a $lookup stage.

await orders.aggregate([
  { $lookup: { from: "customers", localField: "customerId", foreignField: "_id", as: "customer" } },
  { $unwind: "$customer" },
  { $lookup: { from: "loyaltyTiers", localField: "customer.tierId", foreignField: "_id", as: "customer.tier" } }
]).toArray();

🔁 18. Recursive Relationships

Use $graphLookup's maxDepth option to bound how far a recursive relationship traversal goes, preventing runaway queries on deep or cyclic hierarchies.

{
  $graphLookup: {
    from: "categories",
    startWith: "$parentId",
    connectFromField: "parentId",
    connectToField: "_id",
    as: "ancestors",
    maxDepth: 5
  }
}

⚡ 19. Relationship Performance

🔐 20. Data Consistency

Since MongoDB has no foreign key enforcement, keeping references valid — and duplicated fields in sync — is the application's responsibility.

🏛️ 21. Relationship Design Patterns

Real applications typically combine several relationship styles. An order might embed its line items, reference its customer, and denormalize the customer's name for display.

{
  _id: ObjectId("o1"),
  customerId: ObjectId("c1"),      // reference
  customerName: "Alice",           // denormalized
  items: [                         // embedded
    { productId: ObjectId("p1"), name: "Mouse", qty: 2 }
  ]
}

🌟 22. Best Practices

⚠️ 23. Common Mistakes

❓ 24. Frequently Asked Questions

📌 25. Summary