How would you use MongoDB zone sharding to keep recent data on fast shards and older data on cheap shards?

## Why zones can express tiering at all Zone sharding constrains which shards may hold which shard-key ranges. If the leading field of the shard key is time-ordered, then ranges *are* time windows, and a rule about ranges becomes a rule about age. That is the whole trick: the same mechanism used for geographic residency becomes hot/cold tiering purely by changing what the leading field means. ## The design **Shard key.** Something like `{month: 1, deviceId: 1}` where `month` is a bucketed period such as `"2026-08"`, or a date field truncated to a period. Buckets are usually better than raw timestamps: they give you a small, predictable number of boundaries to manage, and each roll moves one well-understood unit of data. **Zones.** `sh.addShardToZone("shard-nvme-0", "hot")` for the fast shards, `sh.addShardToZone("shard-hdd-0", "archive")` for the cheap ones. Nothing prevents the two tiers having different instance sizes, disk types or even member counts. **Ranges.** Everything from the cutoff up to `MaxKey` maps to `hot`; everything from `MinKey` to the cutoff maps to `archive`. Cover the full key space so no range escapes onto the wrong tier. **The roll-forward job.** Nothing about the cutoff is automatic. A scheduled job must remove the boundary ranges and re-declare them with the new cutoff, after which the balancer drains the newly-aged period down to archive: ```javascript const oldCut = "2026-05", newCut = "2026-06"; sh.removeRangeFromZone("app.readings", { month: oldCut, deviceId: MinKey }, { month: MaxKey, deviceId: MaxKey }); sh.updateZoneKeyRange("app.readings", { month: MinKey, deviceId: MinKey }, { month: newCut, deviceId: MinKey }, "archive"); sh.updateZoneKeyRange("app.readings", { month: newCut, deviceId: MinKey }, { month: MaxKey, deviceId: MaxKey }, "hot"); ``` That job is production code: it needs idempotency, alerting when it does not run, and a check that the previous roll actually converged before the next one starts. ## The capacity question that decides whether this works Every roll pushes one period of data across the network. The cluster can run at most about *n*/2 concurrent migrations for *n* shards, each move copies a range's worth of bytes, and migrations only start inside the balancer's active window. Multiply it out before committing: if a month is 4 TB and your nightly window realistically moves 200 GB, the tier never converges and you are permanently mid-migration, paying the IO cost without ever getting the placement. Levers if the arithmetic fails: shorter buckets so each roll is smaller and more frequent; a wider or continuous balancer window with `_secondaryThrottle` to protect replication instead of a hard time limit; more shards in each tier to raise migration parallelism; or abandoning migration-based tiering in favour of writing cold data to a separate cluster or an object store. ## The costs you are signing up for **Insert concentration.** A time-ordered leading shard-key field means all new writes land in the newest range on one shard. The hot tier must be sized for the entire write rate, not for its share of the data, and adding hot shards does not spread inserts. This is an accepted consequence of making tiering expressible, and you should say so out loud rather than pretend the balancer will fix it. **Archive-tier read latency.** Queries touching old periods land on slow disks. That is the point, but it must be a product decision: if reporting regularly scans two years, the archive tier is on the critical path of a user-visible feature. **Scatter-gather on non-time queries.** A query without the leading field fans out across both tiers, so its latency is set by the slowest tier. Access patterns that ignore time undermine the whole arrangement. **Permanent background load.** Unlike a one-off rebalance, tiering means the cluster is always moving data. Range deletion on the donors is continuous too, and the orphan backlog needs watching. ## When not to do this If old data is only ever deleted, a TTL index and a shard key chosen for query locality are simpler and cheaper than moving data you are about to discard. If old data is read a few times a year, exporting it out of the operational cluster entirely usually beats keeping it online on slow shards. Migration-based tiering earns its keep when cold data must stay queryable through the same collection, with the same code paths, and the cost difference between tiers is large enough to pay for the movement. ## What to monitor Whether the roll job ran; whether the previous roll converged (per-shard byte totals per tier); migration throughput from `config.changelog`; range-deletion backlog on donors; replication lag on recipients; and the write latency on the newest range, which is the single most likely thing to degrade first.