# Zone sharding for tiered hardware (hot, warm, cold) > Source-anchored research for Zone sharding for tiered hardware (hot, warm, cold). Run status: COMPLETED. Parent: [Independent shard scaling and per-shard tiering](https://llms-explorer.com/tree/independent-shard-scaling-and-per-shard-tiering/) · 5 facets · 13 facts · page: https://llms-explorer.com/tree/zone-sharding-for-tiered-hardware-hot-warm-cold/ ## How it works - Hot, warm, and cold are operator-defined zone names and hardware choices, not fixed MongoDB storage classes. MongoDB documents a fast recent tier and a slower archive tier; a third intermediate tier extends the same range-placement mechanism. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - Rolling retention tiers require an operator or automation to update absolute date boundaries. The balancer enforces the configured ranges; a fixed boundary does not advance merely because documents become older. Rotation frequency trades operational frequency against migration volume per rotation. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) ## How-to and procedures - To benefit from targeted reads, queries should include the relevant shard key or usable prefix. Queries without it can broadcast across shards, so a cold tier can remain part of an application read path even when most user-facing data is recent. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - Configure zone placement before allowing newly added low-spec shards to receive ordinary balancing traffic. Percona warns that adding those shards with the balancer running can move unintended data; MongoDB's hardware-tier tutorial stops balancing while configuring zones. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) ## Problems, failure modes and limitations - A reported hot/cold configuration with shard key order {id, ts} used MinKey-to-MaxKey spans for id in both ranges and failed with an overlapping-zone-range error. This illustrates why a trailing timestamp cannot be treated as an independent age partition across every leading id. (medium confidence) — [source](https://dba.stackexchange.com/questions/258466/mongodb-shard-zone-range-overlapping) - Zone configuration needs eligible destination shards. The balancer policy warns that chunks in a zone with no assigned shards cannot be balanced, so a tier label and its date ranges alone do not provision working cold capacity. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) ## Comparisons and alternatives - Age-based placement needs a shard key whose ordered ranges can distinguish the ages being separated. A creation-date prefix can support this; hashing the age field makes its zone ranges operate on hash values rather than chronological intervals. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - Zone intervals include their lower bound and exclude their upper bound, and cannot overlap. Derived ordering consequence: when the leading date and field names are equal, an upper bound ending in MaxKey sorts above a lower bound ending in MinKey. Those bounds leave an overlapping key interval rather than being the same adjacent boundary; use matching complete compound-key boundaries. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) ## Facts and statements - Zone sharding maps shard-key ranges to named groups of shards. Assigning recent and archival ranges to shards with different hardware lets one collection serve data with different latency requirements. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - Cold-shard economics depend on having substantial rarely accessed data and accepting slower reads for it. Smaller RAM and CPU allocations and slower, higher-capacity disks can reduce infrastructure cost, but these sources do not establish a generally applicable savings percentage. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - Zone changes converge through chunk migrations. Existing chunks can violate the new placement rules until balancing completes, and migration activity can affect cluster performance; plan rotation timing and verify final placement. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - Ranges outside all configured zones may reside on any shard. Cover the intended chronological domain explicitly if hot/warm/cold hardware placement must apply to all records. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - A monotonically increasing timestamp used for range sharding can concentrate new writes on the highest-key chunk and its shard. Hardware tiering therefore does not by itself distribute concurrent new inserts across the hot shards. (high confidence) — [source](https://www.percona.com/blog/when-should-i-enable-mongodb-sharding/)