# Hashed vs ranged shard key query trade-offs > Source-anchored research for Hashed vs ranged shard key query trade-offs. Run status: COMPLETED. Parent: [MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting](https://llms-explorer.com/tree/mongodb-query-shape-optimization-sort-pagination-operators-and-sharded-targeting/) · 3 facets · 13 facts · page: https://llms-explorer.com/tree/hashed-vs-ranged-shard-key-query-trade-offs/ ## 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](https://www.mongodb.com/docs/manual/core/ranged-sharding.md) ## 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - 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](https://github.com/yorkie-team/yorkie/issues/673) ## 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](https://www.mongodb.com/docs/manual/core/ranged-sharding.md) - 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - 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](https://www.alibabacloud.com/help/en/mongodb/use-cases/introduction-to-apsaradb-for-mongodb-sharded-cluster-instances) - 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - 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](https://jira.mongodb.org/browse/SERVER-72987) - 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](https://www.alibabacloud.com/help/en/mongodb/use-cases/introduction-to-apsaradb-for-mongodb-sharded-cluster-instances) - 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - 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](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key.md) - 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md)