<!-- llms-explorer concept facts · https://llms-explorer.com/tree/balancer-data-size-policy-and-zone-aware-migration/ · pack 2026-10-23 · ~945 tokens -->

# Balancer data-size policy and zone-aware migration

> Source-anchored research for Balancer data-size policy and zone-aware migration. 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 · 8 facts · page: https://llms-explorer.com/tree/balancer-data-size-policy-and-zone-aware-migration/

## How it works

- Adding, removing, or changing zones or zone ranges can trigger chunk migrations. The amount of affected data and chunks can affect cluster performance, so MongoDB recommends scheduling balancing windows. Defining zones and ranges before sharding an empty or nonexistent collection lets MongoDB create and initially distribute chunks using those zones. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas/)
- Data-size balance does not establish workload balance: Percona treats workload distribution as a separate goal, while MongoDB describes the balancer's trigger in terms of collection data size. (medium confidence) — [source](https://www.percona.com/blog/mongodb-new-balancer-policy-and-automerger/)

## Problems, failure modes and limitations

- Configured chunkSize influences the maximum data amount the balancer attempts to move per migration, but it is not a hard size cap for stored chunks: MongoDB documents chunks that exceed the configured size when an indivisible range cannot be split. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/sharding-balancer-administration/)

## Comparisons and alternatives

- Starting in MongoDB 6.1, the balancer distributes sharded data by collection data size rather than chunk count. The manual says a collection is balanced while its shard data-size difference is below three times the configured `chunkSize`; at the default 128 MB, a difference of 384 MB or more can trigger migration. Separately, Alibaba's ApsaraDB guide reports a trigger above 384 MB for its 128 MB default. Alibaba's support article scopes ApsaraDB's size-based policy to its MongoDB 6.0 minor 7.0.1 and later (mapped by Alibaba to community MongoDB 6.0.3); it lists minor 7.0.0 as chunk-count-based. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v7.0/release-notes/7.0/)

## Facts and statements

- Zone ranges constrain migration destinations: a chunk whose shard-key range falls within a zone can migrate only to a shard assigned to that zone. A range outside all zones may reside on any shard. Zone placement is not instantaneous; until balancing completes, chunks can still violate newly configured zones. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding/)
- MongoDB's procedure for changing zones on an existing collection disables the balancer and waits for any active balancing round to finish before changing zone assignments and ranges; balancing is then re-enabled to move data into compliant locations. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/tutorial/sharding-tiered-hardware-for-varying-slas/)
- MongoDB documents hardware and performance placement as a use for zones, but zone boundaries must use shard-key fields; with a compound shard key, a zone range must include the shard-key prefix. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding/)
- MongoDB's manual says zone sharding is unsupported for time-series collections, which the balancer instead distributes evenly across all shards. (low confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/manual/core/zone-sharding/)
