What are common MongoDB data modeling patterns?

Question

Accepted Answer

Beyond the basic embed-vs-reference decision, MongoDB has established **data modeling patterns** — proven solutions for common scenarios like large arrays, polymorphic data, and relationships. Knowing them helps you design effective schemas for real situations.

## The Bucket pattern — group time-series/related data

```js
// instead of one document per reading (millions of tiny docs), BUCKET them:
{
  sensorId: "s1",
  date: ISODate("2024-01-15"),
  readings: [                            // a day's readings in one document
    { time: "10:00", value: 23 },
    { time: "10:01", value: 24 }
  ]
}
// → fewer documents, efficient for time-series/IoT data
```

## The Subset pattern — embed a frequently-used subset

```js
// embed the most-used part, reference the rest (for large related data)
{
  _id: ObjectId("..."),
  title: "Product",
  recentReviews: [ /* 5 most recent — embedded for fast display */ ],
  // full reviews live in a separate collection (referenced)
}
// → fast common reads without loading ALL related data
```

## The Computed pattern — precompute and store

```js
// store precomputed values (avoid recomputing on every read)
{ productId: "p1", totalReviews: 1500, avgRating: 4.5 }
// → update these when reviews change; reads are fast (no aggregation needed)
```

## The Extended Reference pattern — embed key reference fields

```js
// embed the OFTEN-NEEDED fields of a referenced document (avoid a join for common reads)
{ orderId: "o1", customer: { _id: "u1", name: "Ann", city: "NY" } }  // enough for display
// → reference customer._id for full data; embed name/city for the common read
```

## Other patterns

```text
Polymorphic    → different document shapes in one collection (with a "type" field)
Schema Versioning → a version field to handle evolving schemas in one collection
Outlier        → handle rare documents that don't fit the common pattern specially
Approximation  → store approximate values (e.g. view counts) to reduce write load
Tree/Hierarchy → patterns for hierarchical data (parent refs, arrays of ancestors, etc.)
```

## Why it matters

Understanding common MongoDB data modeling patterns is valuable for **designing effective schemas for real-world scenarios**, so it's useful knowledge that builds on the basic embed-vs-reference decision.

While embedding vs referencing is the core choice, real applications face recurring modeling challenges that these proven patterns address: the **Bucket pattern** (grouping time-series/IoT readings into fewer documents — important for the common time-series use case, avoiding millions of tiny documents), the **Subset pattern** (embedding a frequently-used subset while referencing the full data — balancing read performance with document size for large related data), the **Computed pattern** (precomputing and storing values like totals/averages to avoid expensive recomputation on reads), the **Extended Reference pattern** (embedding often-needed fields of referenced documents to avoid joins for common reads — a practical hybrid), and others (polymorphic for varied shapes, schema versioning for evolution, tree patterns for hierarchies).

Knowing these patterns provides **proven solutions** for common scenarios rather than reinventing designs, helping you make sound modeling decisions for situations like time-series data, large related collections, expensive computations, and hierarchical data.

Since real MongoDB applications face these recurring design challenges, and since established patterns provide tested, effective solutions (improving performance and maintainability), understanding common MongoDB data modeling patterns — the bucket, subset, computed, extended reference, and other patterns — is valuable, practically-relevant knowledge that elevates schema design from basic embed/reference choices to applying proven solutions for real scenarios, reflecting mature MongoDB design skill and helping build schemas that perform well for an application's specific access patterns and data characteristics.