Zone sharding and region-aware 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 region-aware 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.
Structure and components
- The documented {country: 1, userid: 1} design uses country for regional zones and userid for higher cardinality and lower value frequency than country alone. A region-only key forfeits that finer distribution component. (low confidence) [source]
- In the documented country-prefixed design, including country lets reads target the relevant shard subset; omitting country broadcasts reads. A regional zone can contain multiple shards, so providing only the regional prefix does not guarantee a single-shard query. (medium confidence) [source]
How it works
- Historical bug SERVER-73848 documented conflicting old and new config.tags ranges, or duplicate-key errors, when resharding from a hashed key to the same field without hashing. The issue records fixes in 5.0.19, 6.0.7, 7.0.0-rc3 and 7.1.0-rc0; this is historical upgrade evidence, not proof that current releases retain the defect. (low confidence) [source]
- The 2021 University of Piraeus study of spatio-temporal MongoDB workloads used zones to preserve locality and found that fewer nodes processed some queries. Several larger queries became slower because reduced parallelism increased work per participating node; this workload-specific result is not a benchmark of regional deployment costs. (low confidence) [source]
Problems, failure modes and limitations
- A geographic field must lead the shard key when zones partition directly by geographic location: zone bounds must contain the shard-key prefix and cannot use fields outside the shard key. (medium confidence) [source]
- Zone ranges include their lower bound and exclude their upper bound, and ranges cannot overlap. Boundary tests should include exact endpoints when validating regional mappings. (medium confidence) [source]
Comparisons and alternatives
- Changing zone assignments does not relocate existing data immediately: placement may violate the new policy until balancing completes. Treat the transition as a placement-verification requirement rather than assuming that successful configuration means immediate residency. (medium confidence) [source]
- A zone can cover multiple country values: MongoDB's location tutorial places both UK and DE in one EU zone. This permits regional resource sharing instead of requiring a separate shard or zone for every country. (low confidence) [source]
Facts and statements
- Zone sharding associates shard-key ranges with one or more eligible shards; a shard may belong to multiple zones. In a balanced cluster, data covered by a zone resides on shards assigned to that zone. (medium confidence) [source]
- The cost-lever inference is to include the geographic prefix in frequent regional reads and confirm targeting with explain(): avoiding unnecessary cross-shard work can reduce resource demand, but the sources do not provide a general savings percentage. (medium confidence) [source]
- The ArchTenet author describes an unnamed production episode in which geo-sharding without region predicates and suitable indexes increased work across shards and increased the database bill. The article labels its pricing illustrative; this is not an independently audited cost benchmark. (low confidence) [source]
- Documents outside every configured zone range may reside on any shard. Regional placement therefore requires explicit coverage of all relevant geographic values, including newly introduced values. (medium confidence) [source]
- Defining zones and their ranges before sharding an empty collection enables initial placement consistent with those zones. Changing a populated collection’s zone mapping can require a period of redistribution, so new regional placement is not instantaneous. (medium confidence) [source]
- Zones determine which shards own a range; they do not alone guarantee that every replica stays in that geography. Atlas Global Cluster documentation describes distributing a zone’s shard members among its configured regions, so residency assessment must also inspect replica-region configuration. (medium confidence) [source]
- Zones also support assigning selected data to shards with suitable hardware. The cost opportunity is a placement policy matched to workload needs; neither the manual nor Percona’s example establishes a measured total-cost reduction. (medium confidence) [source]
- Zone ranges must use shard-key fields and include the compound key's prefix. For country-based placement, MongoDB's tutorial uses {country: 1, userid: 1}: country defines geographic groups, while userid contributes higher cardinality and lower frequency than country alone. (medium confidence) [source]
- Geographic zones can place data closer to the applications that use it, reducing network latency and overhead. This identifies a potential cost lever, but neither cited source quantifies a generally applicable financial saving. (medium confidence) [source]
- Percona warns that location-based sharding can produce data skew and require additional infrastructure for multi-site deployments. Its guidance recommends monitoring both per-shard data volume and query load; geographic grouping does not itself ensure even resource use. (low confidence) [source]
Children
- Geographic prefix selection and regional query targeting (frontier)
- Zone-range coverage and boundary validation (frontier)
- Replica geography versus shard ownership (frontier)
- Measuring regional placement cost effects (frontier)
Frontier under this node: Geographic prefix selection and regional query targeting, Measuring regional placement cost effects, Replica geography versus shard ownership, Zone-range coverage and boundary validation