How do you model relationships in MongoDB?

Question

Accepted Answer

MongoDB models relationships (one-to-one, one-to-many, many-to-many) through **embedding** or **referencing** — the choice depends on the relationship's cardinality, how the data is accessed, and whether it's shared. Unlike SQL's uniform foreign-key approach, MongoDB offers flexibility per relationship.

## One-to-one

```js
// usually EMBED (the related data belongs to the document)
{ _id: ObjectId("..."), name: "Ann", profile: { bio: "...", avatar: "..." } }
// → one query gets both; they're accessed together
```

## One-to-many (the most common — and most nuanced)

```js
// ONE-TO-FEW → embed (bounded, accessed together)
{ _id: ObjectId("..."), name: "Ann", addresses: [ {...}, {...} ] }  // a few addresses

// ONE-TO-MANY → reference (the "many" side references the "one")
// authors collection: { _id: "a1", name: "Ann" }
// books collection:   { _id: "b1", authorId: "a1", title: "..." }  // each book references its author

// ONE-TO-SQUILLIONS (huge/unbounded) → ALWAYS reference (never embed unbounded data)
// e.g. a user with millions of log entries → separate collection, reference by userId
```

The key nuance: **one-to-few** (embed), **one-to-many** (reference from the many side), **one-to-squillions** (always reference — never embed unbounded data, due to the 16MB document limit and performance).

## Many-to-many

```js
// reference with an array of ids (on one or both sides)
{ _id: "s1", name: "Student", courseIds: ["c1", "c2"] }     // student → courses
{ _id: "c1", name: "Course", studentIds: ["s1", "s2"] }     // course → students (optional)
// → query and $lookup to resolve; or a separate "enrollments" collection (junction-like)
```

Many-to-many uses arrays of referenced ids (on one or both sides), or a separate junction-like collection for rich relationship data.

## Resolving references ($lookup)

```js
// join referenced data when needed
db.books.aggregate([
  { $lookup: { from: "authors", localField: "authorId", foreignField: "_id", as: "author" } }
]);
```

## Why it matters

Modeling relationships is fundamental to database design, and MongoDB's flexible, access-pattern-driven approach is different from SQL's uniform foreign keys, so understanding how to model relationships in MongoDB is essential for designing effective schemas.

The key insight is that MongoDB models relationships through **embedding or referencing** based on the relationship's characteristics — and understanding **how cardinality affects the choice** is the crucial skill: **one-to-one** (usually embed — accessed together), **one-to-many** with its important nuances (**one-to-few** → embed for bounded together-accessed data; **one-to-many** → reference from the many side; **one-to-squillions** → always reference, never embedding unbounded data due to the 16MB document limit and performance), and **many-to-many** (arrays of referenced ids, or a junction-like collection).

This cardinality-driven decision-making (especially recognizing when data is too large/unbounded to embed) is essential for avoiding common mistakes like embedding unbounded arrays (bloating documents, hitting limits) or over-referencing data that should be embedded.

Understanding how to **resolve references** with `$lookup` when joins are needed completes the picture.

Since relationships between entities are inherent in most data models, and since MongoDB's flexible per-relationship approach (embed vs reference based on cardinality and access patterns) is fundamentally different from and more nuanced than SQL's uniform foreign keys, understanding how to model relationships in MongoDB — the cardinality-based embed/reference decisions (especially the one-to-few/many/squillions distinction) and resolving references — is essential, frequently-applied knowledge for effective MongoDB schema design, building on the embed/reference fundamentals to handle the relationships every real application has, and a key area distinguishing sound MongoDB modeling from naive relational ports.