Shard key selection for query isolation
Parent: MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting · Published reference · snapshot 2026-10-21 · skill ranked-b37a4eca
↓ Facts as markdownall context files
Source-anchored research for Shard key selection for query isolation. 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
- High cardinality alone does not ensure even distribution: frequent shard-key values can bottleneck chunks, while monotonically increasing or decreasing values can concentrate new inserts on the MaxKey or MinKey range. Evaluate value frequency and insert patterns alongside cardinality when selecting a key. (high confidence) [source]
- Scatter-gather is valid for some workloads: MongoDB documents that it can parallelize large aggregations. Repeated cross-shard requests for routine queries, however, add fan-out and do not scale linearly with shard count. A community discussion records a counterpoint that scatter-gather may help when each shard's working set fits in memory, then challenges whether that benefit survives the extra work as shards are added; evaluate the exception against the actual workload. (high confidence) [source]
- MongoDB can target a query containing the full shard key or a prefix of a compound shard key to the shard or shards holding the matching data. Queries without shard-key fields are generally broadcast to all shards, so frequent request filters should align with the shard key when query isolation matters. (high confidence) [source]
Problems, failure modes and limitations
- An ordinary index on a non-shard-key field does not give mongos shard-level query isolation. A predicate that includes the shard key or a compound-key prefix can target the shard or subset that owns matching data; when mongos cannot determine the location from the predicate, it generally broadcasts to all shards. (high confidence) [source]
Comparisons and alternatives
- Choose a key against the dominant query and write workload rather than a convenient field. MongoDB describes the ideal key as one that distributes data evenly and facilitates common query patterns. Percona illustrates the tradeoff with a posts collection whose post_id key isolates single-post reads, even though append writes can concentrate on one shard. AWS gives similar query-frequency, usage-pattern, and cardinality guidance for Amazon DocumentDB Elastic Clusters; that is cross-system support for the selection heuristic, not evidence about MongoDB routing. (high confidence) [source]
Facts and statements
- Choose a shard key against both common query patterns and distribution needs. MongoDB recommends a key that distributes data evenly while facilitating common query patterns; Percona describes the practical balance as spreading insertions while serving each query from as few shards as possible, ideally one. (high confidence) [source]
- Scatter-gather has workload-dependent value: MongoDB says multi-shard requests are less efficient and do not scale linearly as shards are added, while large aggregations can benefit from parallel execution across shards. Even a query containing shard-key fields may still broadcast depending on data distribution and query selectivity. (high confidence) [source]
- MongoDB documents that analyzeShardKey uses sampled queries to report shard-key characteristics and read/write-distribution metrics, including query routing and shard-key-range load; operators can use these measurements to compare candidate keys against observed workload. (low confidence) (verified as of 2026-10-19) [source]
- AWS's Amazon DocumentDB Elastic Clusters guidance, scoped to that MongoDB-compatible service, says shard keys distribute read and write traffic and recommends considering query frequency, usage patterns, and key cardinality. This independently supports workload-aware key selection, but it does not establish MongoDB server routing behavior. (medium confidence) [source]
Children
- Compound shard-key prefix targeting (frontier)
- Hashed versus ranged shard-key tradeoffs (frontier)
- analyzeShardKey workload sampling (frontier)
Frontier under this node: Compound shard-key prefix targeting, Hashed versus ranged shard-key tradeoffs, analyzeShardKey workload sampling