When should you choose a hashed shard key in MongoDB instead of a ranged one, and what do you give up?

## The two partitioning strategies When you shard a collection you pick not just which field or fields form the key, but how MongoDB derives ranges from them. Ranged sharding divides the key space into contiguous intervals of the actual values: shard A owns keys from `MinKey` to 1000, shard B owns 1000 to 5000, and so on. Hashed sharding applies a hash function to the key value and divides the space of *hash* outputs instead. You choose it in the shard key specification itself: `{ userId: 1 }` is ranged, `{ userId: "hashed" }` is hashed. The underlying index differs too — a hashed shard key is backed by a hashed index. ## What hashing buys you The hash of a monotonically increasing sequence is not monotonic. That single property is the main reason hashed sharding exists. Sharding a high-volume event collection on `{ _id: 1 }` when `_id` is a default `ObjectId` funnels every insert into the top range and thus onto one shard, because `ObjectId` values encode creation time in their leading bytes and therefore rise over time. Sharding on `{ _id: "hashed" }` scatters consecutive inserts across the whole hash space, so writes land roughly uniformly on all shards from the first document. The same applies to any natural key with clumpy ordering — a country code prefix, a sequential invoice number, a device serial that increments per batch. A second benefit is that even distribution is achieved without you designing a compound key or pre-splitting anything: the hash function does the spreading. ## What hashing costs you Hashing destroys order, and everything that depended on order goes with it. **Range targeting.** With a ranged key on `createdAt`, a query for the last hour hits only the shards owning the top few ranges. With `{ createdAt: "hashed" }`, that hour's documents are scattered uniformly, so `mongos` must ask every shard and merge the results. For a dashboard whose whole workload is recent-window queries, hashing the timestamp trades a write hotspot for a read fan-out on every query. **Zone-based placement by value.** Pinning a value range to specific shards depends on the shard key preserving order, so it does not work on a hashed field. **Equality is still fine.** This is the part candidates most often get wrong in both directions. A hash function is deterministic, so `find({ userId: 42 })` on a `{ userId: "hashed" }` collection computes one hash and routes to the single shard owning it. Hashed sharding does *not* make every query a broadcast — only order-dependent ones. ## Compound hashed keys Since MongoDB 4.4 a compound shard key may include exactly one hashed field, in either the prefix or a later position. `{ deviceId: "hashed", ts: 1 }` spreads devices evenly across the cluster while giving each device's documents an ordered suffix that ranges can be split on, so no single device's data becomes indivisible. `{ tenantId: 1, sessionId: "hashed" }` keeps a tenant's data in an ordered, zone-pinnable prefix while ensuring the tenant's own documents scatter within it. This flexibility removes much of the old all-or-nothing feel of the choice. ## Caveats worth knowing Hashed indexes do not support arrays: you cannot hash a field whose values are arrays, so a multikey field is not a valid hashed shard key. Hashed indexes also do not support the unique option. And hashing collapses floating-point values that differ only in their fractional part, because values are converted to 64-bit integers before hashing — so a `price` field with cents is a bad hashed key, since many distinct prices map to the same hash and the resulting group becomes indivisible. ## How to decide Write the collection's real access patterns down, then ask two questions. First, does the natural key increase over time or cluster its values? If yes, ranged sharding on it alone will hotspot. Second, does the workload depend on value-ordered access — recent-window scans, ordered pagination across the key, zone placement? If yes, hashing that field pushes the cost onto every read. When both answers are "yes" — a time-series workload that both inserts monotonically and queries by time window — the usual answer is neither pure form but a compound ranged key whose prefix is a non-monotonic, high-cardinality dimension, such as `{ deviceId: 1, ts: 1 }`. Each device's writes spread by device, and a query for one device's last hour is still targeted. Reaching for a compound key rather than defaulting to hashed is what separates a considered answer from a memorised one.