Hashed vs ranged shard key query trade-offs
Parent: MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting · Published reference · snapshot 2026-10-24
↓ Facts as markdownall context files
Source-anchored research for Hashed vs ranged shard key query trade-offs. 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
- Choose the key and distribution strategy from the workload: frequent selective ranges favor preserving range locality, whereas monotonic insert pressure can favor hashing. Test both data skew and common query predicates because good write distribution alone does not establish good read performance. (high confidence) [source]
Problems, failure modes and limitations
- For a single-field hashed shard key, a range predicate on the original field cannot exploit its natural order for shard pruning and generally requires scatter-gather across owning shards. This is a routing penalty, not a prohibition on range queries. (medium confidence) [source]
- Yorkie’s sharding design selected ranged project_id and doc_id keys around project- and document-scoped queries, including pagination and sequence ranges. The same design records high project_id frequency as a scalability risk and proposes a compound key as a possible remedy. (low confidence) [source]
Facts and statements
- Ranged sharding partitions the original shard-key value space into contiguous ranges. Nearby values can share a chunk or shard, allowing selective range queries to contact only the shards holding the relevant ranges; a range query is not guaranteed to reach just one shard. (high confidence) [source]
- For a monotonically increasing ranged shard key, new inserts concentrate in the chunk ending at MaxKey and its owning shard. Hashing a sufficiently diverse key spreads inserts across the hash space and can relieve this write bottleneck. (high confidence) [source]
- mongos can route an equality match on a single-field hashed shard key to one shard; MongoDB computes the hash internally, so applications supply the original value. (high confidence) [source]
- Hashing does not create new distinct values or split documents sharing the same complete shard-key value. Low cardinality and frequent repeated values can still concentrate data and workload; a discriminating compound key can provide additional split points. (high confidence) [source]
- Compound hashed keys can retain non-hashed leading fields for zone ranges while hashing another field for distribution. Zone ranges on a hashed field refer to hash values, so they do not preserve the original field’s geographic or numeric ordering. (medium confidence) [source]
- MongoDB SERVER-72987 documents a historical analyzeShardKey classification bug: it treated hashed-key range queries as targeting a variable subset of shards although they target all shards. The issue records a fix for 6.3.0-rc0; this historical record does not establish a defect in current releases. (low confidence) [source]
- A hashed timestamp can spread IoT log writes while device-ID reads still contact all shards. Alibaba’s workload example instead recommends a ranged device-ID-plus-timestamp key for frequent per-device time-window queries; this recommendation depends on the stated workload. (low confidence) [source]
- Hashing a shard-key field destroys locality in its original value order. A range predicate on that hashed field therefore loses the routing advantage of ranged sharding and is more likely to require a cluster-wide broadcast. (high confidence) [source]
- For ordinary reads without a usable shard-key predicate or compound-key prefix, mongos must broadcast to the shards and merge their results. Switching between hashed and ranged placement does not by itself fix an access pattern that omits the routing key. (high confidence) [source]
- Compound hashed keys can combine non-hashed leading fields with a hashed field. A usable leading-key predicate can restrict routing to a shard set, while hashed values distribute data within that scope; a prefix predicate need not identify one shard. (high confidence) [source]
Children
- Compound hashed shard-key prefix targeting (frontier)
- Shard-key cardinality and hot-value skew (frontier)
- Range routing versus per-shard index execution (frontier)
- Shard-key cardinality and hot-value frequency (frontier)
- Monotonic shard keys and write hotspots (frontier)
Frontier under this node: Compound hashed shard-key prefix targeting, Monotonic shard keys and write hotspots, Range routing versus per-shard index execution, Shard-key cardinality and hot-value frequency, Shard-key cardinality and hot-value skew