What is MongoDB's bucket pattern, and when does bucketing sensor readings beat one document per reading?

## The problem bucketing solves Time-series and event workloads emit a torrent of tiny records: one temperature reading, one page view, one price tick. Modelled naively that is one document per event. Each document carries its own `_id`, its own entry in the `_id` index, a full copy of every field name inside the BSON, and per-record overhead in the storage engine. The measurement itself might be twenty bytes; the container around it is often larger. At hundreds of millions of events the fixed costs, not the payload, dominate storage and — more importantly — cache. An index that no longer fits in RAM turns every read into disk work. A second problem is read shape. Nobody asks for one reading. They ask for "the last six hours for sensor s-42", which against one-document-per-reading means thousands of index entries and thousands of document fetches for one chart. ## What the pattern is The bucket pattern collapses many records that are always read together into one document. The grouping key is normally the source plus a time window: ```json { "sensorId": "s-42", "startTs": "2026-08-20T14:00:00Z", "count": 60, "sumTemp": 1302.5, "minTemp": 20.9, "maxTemp": 23.4, "samples": [ { "ts": "2026-08-20T14:00:03Z", "temp": 21.7 } ] } ``` One index entry on `{ sensorId: 1, startTs: 1 }` now locates an hour of data. The rollup fields are the computed pattern applied inside the bucket: the average for the hour is `sumTemp / count` without touching the array at all. ## Writing into buckets The idiomatic write is one upsert per event. The filter identifies the currently open bucket and carries the bound; the update appends and maintains rollups: ```javascript db.readings.updateOne( { sensorId: "s-42", startTs: hourStart, count: { $lt: 200 } }, { $push: { samples: { ts: now, temp: 21.7 } }, $inc: { count: 1, sumTemp: 21.7 }, $max: { maxTemp: 21.7 } }, { upsert: true } ) ``` When the bucket reaches 200 samples nothing matches, so the upsert inserts a new bucket instead of growing the old one past its bound. All of this happens inside one document, so it is atomic without a transaction. ## Choosing the boundary Two bounds matter. The **semantic** bound is the window you query by — bucket by hour if dashboards ask for hours, because a bucket that spans more than the query window forces you to filter the array. The **physical** bound keeps the document small: cap by element count or estimated size so a bucket cannot approach the 16 MB BSON limit, and remember that very large documents make every update more expensive because the storage engine rewrites the document, not just the appended field. ## What you give up Single-event access is no longer a point read: you match the bucket and then filter or `$unwind` the array, and updating one sample needs the positional operators or `arrayFilters`. Deletes and TTL work at bucket granularity, so retention becomes coarser. Uniqueness on an individual measurement is harder to enforce, because a unique index constrains documents, not array elements. And a badly chosen bucket key — bucketing by time alone, mixing every sensor into one document — creates contention on a single hot document. ## Native time series collections From MongoDB 5.0 the server implements this internally. `db.createCollection("readings", { timeseries: { timeField: "ts", metaField: "sensorId", granularity: "hours" } })` gives you a collection you insert one document per measurement into and query as if it were unbucketed, while the storage layer keeps bucketed, column-oriented internals. `expireAfterSeconds` on the collection handles retention. For new time-stamped workloads that is the default answer; hand-rolled bucketing remains the right tool when the grouping is not time-based — batching many small child records under a parent, for example — or when you need the rollups visible as ordinary queryable fields. ## How to answer it Say what the pattern is in one sentence, name where the win comes from (document count, index entries, repeated field names, fewer fetches per range read), show the bounded upsert, then volunteer the costs and the 16 MB ceiling. Finishing with "and on 5.0+ I'd reach for a native time series collection first" is what separates someone who has read the pattern from someone who has run it.