Zone sharding and Global Cluster shard keys
Parent: Shard Key Design and Resharding as Cost Levers · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Zone sharding and Global Cluster shard keys. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- Atlas can hash the secondary Global Writes key and pre-split an empty or nonexistent collection by defined zones and ranges. Initial chunk distribution is a setup mechanism, not evidence of balanced application load. (low confidence) (verified as of 2026-10-14) [source]
Measurements and reference values
- Historical issue SERVER-37810 reproduced expensive zone-membership checks with over one million chunks in MongoDB 3.4.16 and 4.0.3. Its reproduction spent 90% of balancing time finding a candidate. This is historical evidence, not a benchmark for current releases. (low confidence) [source]
Problems, failure modes and limitations
- Zone ranges include their lower boundary and exclude their upper boundary; ranges assigned to zones cannot overlap. (high confidence) [source]
- For Atlas-managed Global Writes, every document must contain location as a supported country or subdivision code. Atlas requires a two-field compound shard key: unhashed location first and one custom secondary field, which may be hashed but cannot be an array. (low confidence) (verified as of 2026-10-14) [source]
- Atlas documents that collections on a Global Cluster cannot be resharded in any MongoDB version. Its separate support for adding shard-key fields through the Atlas UI must not be read as permission to replace the key through resharding. (low confidence) (verified as of 2026-10-14) [source]
- Atlas documents that collections on Global Clusters cannot be resharded in any MongoDB version. Its table separately permits adding shard-key fields through the Atlas UI for MongoDB 7.0 and 8.0; changing a document's key value is another distinct operation. (low confidence) (verified as of 2026-10-14) [source]
Comparisons and alternatives
- A geographic field alone can create bottlenecks when a few locations dominate writes. A compound key supplies additional partitioning granularity; evaluate the secondary field against distribution and query needs instead of assuming country-level placement balances workload. (medium confidence) [source]
- A hashed zone field defines ranges over hash outputs rather than original values. Use an unhashed geographic prefix when geographic codes must map predictably to zones. (medium confidence) [source]
Facts and statements
- A zone associates shard-key ranges with one or more shards; after balancing, covered chunks reside only on shards assigned to that zone. A shard may belong to multiple zones. (high confidence) [source]
- Zone ranges must use shard-key fields and include the compound-key prefix. Geographic placement therefore needs a geographic leading field; adding an unrelated location index does not create geographic zones. (medium confidence) [source]
- Zones can direct selected workloads to particular hardware. Percona demonstrates assigning the heavier subject group to a better-equipped shard; OneUptime illustrates hot/warm/cold hardware tiers. These are placement patterns, not measured cost-saving results. (medium confidence) [source]
- Atlas Global Cluster location codes map automatically to the closest geographical zone; custom zone mappings can override that assignment, including mapping to a more distant zone. (low confidence) (verified as of 2026-10-14) [source]
- Zone configuration changes do not instantly relocate existing data: the balancer migrates violating chunks over time. Chunks outside every configured zone may reside on any shard. (medium confidence) [source]
- Atlas-managed Global Writes uses a compound shard key beginning with location and a custom secondary field. Atlas warns that location alone can bottleneck countries or subdivisions receiving most writes. (medium confidence) (verified as of 2026-10-14) [source]
- Atlas can hash the secondary field and pre-split an empty or nonexistent Global Writes collection according to zones. The location prefix remains available for geographic placement while hashing distributes the secondary values. (medium confidence) (verified as of 2026-10-14) [source]
Children
- Geographic prefix and hashed suffix design (frontier)
- Zone range coverage and balancing convergence (frontier)
- Zone range boundaries and shard-key prefixes (frontier)
- Geographic placement and intra-zone distribution (frontier)
- Atlas managed namespaces and custom location mappings (frontier)
Frontier under this node: Atlas managed namespaces and custom location mappings, Geographic placement and intra-zone distribution, Geographic prefix and hashed suffix design, Zone range boundaries and shard-key prefixes, Zone range coverage and balancing convergence