CONCEPT Cited by 1 source

Working-set memory¶

Definition¶

Working-set memory — the subset of a database's data + indexes that is actually accessed by the live query workload within a given time window and therefore needs to reside in memory for steady-state performance. Not the total dataset size and not the full index size — the hot slice of each.

A system where working-set > available cache pages in-and-out constantly, which means each query tends toward disk-latency rather than memory-latency. A system where working-set ≤ cache sits in an entirely different performance regime.

Informally: "the dataset that has to fit in RAM for the database to feel fast."

Common working-set shapes¶

Recent-time-window (write-heavy, time-ordered reads): only the last N hours / days of data is hot. Index on timestamp stays small in the active range; cold data is fine on disk. Most analytics / observability / IoT workloads.
High-cardinality hot tail (large product catalog, long tail of rarely-accessed items + small head of viral items): the top few % of keys dominate access. Working set is key-count-bounded, not data-size-bounded.
Broad low-locality (random reads across the dataset): no hot slice. Working set ≈ entire dataset. The hardest case — capacity planning requires RAM proportional to dataset size.
Index-heavy point lookups (unique-field lookups by secondary index): the index itself, not the data pages, is the hot slice. Common in transactional workloads.

Identifying which shape applies drives schema + index strategy.

Working-set vs WiredTiger cache¶

In MongoDB, "fit in WiredTiger cache" is the operational realization of "working-set fits in memory." The cache is usually ~50 % of system RAM; the OS filesystem cache layers below it; together they form the working-set residence tier.

Empirical diagnostic: observe eviction rate under representative load. Rising evictions under steady workload → working set doesn't fit. Flat evictions + high cache-hit ratio → it does.

MongoDB Cost of Not Knowing Part 3 specifically surfaces the index as the working-set component that didn't fit in appV6R0 (3.13 GB > 1.5 GB cache). Data pages were compressed enough to fit fine; the _id B-tree wasn't.

Levers to fit working set in memory¶

Roughly in order of first-pass preference:

Shrink the schema (what MongoDB's Cost of Not Knowing series does — field-name shortening, data-type tightening, bucket pattern, computed pattern, dynamic schema).
Right-size the bucket window — wider buckets = fewer documents = smaller index. The appV6R0 → appV6R1 pivot.
Drop unnecessary secondary indexes. Every additional index adds its own B-tree to the working set.
Add RAM. Obvious and sometimes correct, but typically the least-efficient lever — cloud RAM costs 10× a storage byte.
Shard. Splits working set across machines. Expensive in operational complexity; last resort.

Working-set vs total dataset. Total dataset is the full on-disk footprint; working set is the hot slice. Capacity planning cares about working set; durability planning cares about total.
concepts/cache-locality — the code-level analogue: CPU cache working set. Same principle (hot subset fits in fast tier); different tier.
concepts/disk-throughput-bottleneck — disk throughput is the symptom when working set doesn't fit. The bottleneck class is usually the signal; working-set sizing is the fix.

Seen in¶

sources/2025-10-09-mongodb-cost-of-not-knowing-mongodb-part-3-appv6r0-to-appv6r4 — appV6R0's 3.13 GB _id index is the working-set component that overflowed the 1.5 GB WiredTiger cache on a 4 GB-RAM test machine, making "memory/cache the limiting factor rather than document size." appV6R1's quarter-bucketing recovered working-set fit by collapsing document count ~3×.
— Berquist canonicalises working-set fit as the primary data-size sharding trigger (not disk capacity — "These days, that's not the problem. For example, Backblaze purchased over 40,000 16TB drives!"). "One thing to consider is how large your working set is, and how much of that fits into RAM. As less of your active data fits in memory and more queries need to read from disk, query latency will increase." Connects working-set sizing directly to the scaling-ladder decision of when to climb from vertical scaling to horizontal sharding.