# Zone sharding for hardware-tiered shards > Source-anchored research for Zone sharding for hardware-tiered shards. Run status: COMPLETED. Parent: [Independent shard scaling and per-shard tiering](https://llms-explorer.com/tree/independent-shard-scaling-and-per-shard-tiering/) · 4 facets · 12 facts · page: https://llms-explorer.com/tree/zone-sharding-for-hardware-tiered-shards/ ## How it works - When adding differently configured shards, Percona recommends pausing balancing during configuration and checking the resulting distribution before resuming normal operation; otherwise ordinary balancing can place unintended data on the new shards. (high confidence) — [source](https://www.percona.com/blog/tactics-to-scale-down-your-mongodb-deployment/) ## Problems, failure modes and limitations - The placement policy must be expressible through shard-key fields. For compound keys, a zone range must include the shard-key prefix; a non-key attribute cannot independently determine a zone. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Zone ranges have inclusive lower bounds and exclusive upper bounds, and cannot overlap; adjacent ranges therefore need matching boundary values to avoid unintended gaps. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - The reviewed balancer implementation rejects recipient shards outside a chunk's zone and logs a warning for a jumbo zone violation. If no appropriate recipient exists and the selected-migrations list is empty, it logs a debug message at verbosity 3. (low confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/s/balancer/balancer_policy.cpp) ## Comparisons and alternatives - On a hashed shard-key field, zone boundaries apply to hashed values rather than the original field values. Such ranges do not preserve ordinary semantic groupings in the same predictable way as ranges on an unhashed field. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) ## Facts and statements - Zones associate shard-key ranges with one or more shards; a shard may belong to multiple zones. This supports placing selected data on shards according to hardware capability. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Chunks outside all configured zone ranges can reside on any shard, including a shard assigned to a hardware zone. Zone membership alone does not reserve that shard exclusively for the intended data subset. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - Changing zone assignments or ranges can leave chunks temporarily on shards that violate the new policy. The balancer migrates those chunks toward compliant shards, and migration work can affect cluster performance. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - The documented configuration workflow associates shards with zones, defines shard-key ranges, and checks balancer activity and chunk distribution. OneUptime demonstrates sh.addShardToZone(), sh.updateZoneKeyRange(), and sh.status(). (high confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding.md) - Including the relevant shard-key predicate lets mongos target the shards holding the requested range; a hardware placement policy by itself does not establish a guaranteed latency improvement for an application query. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - Hardware-based placement can support different service objectives for different data subsets. Percona demonstrates assigning a larger subject workload to a better-configured shard, while OneUptime demonstrates dedicated shards for premium tenants. (high confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md) - Queries that include the shard key can target the relevant shard or shards. Hardware-based placement alone does not establish that every query will avoid a cluster-wide broadcast. (medium confidence) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas.md)