Hash vs Range vs Directory Sharding

Side by side

Criterion	Hash sharding	Range sharding	Directory (lookup) sharding	Don't shard yet
Load balance	Even (except whale keys)	Risk of hot ranges	Controllable per key	n/a
Range queries	Fan out	Local	Depends on placement	Local
Rebalancing	Easy with logical shards / consistent hashing	Split/merge ranges	Move any key	n/a
Operational complexity	Medium	Medium	High (directory is critical)	Lowest

When to choose each

Hash sharding

shard = hash(key) mod N (ideally via many logical shards or a consistent-hash ring).

Choose when

Even spread matters most
Access is by key (tenant, user, conversation)

Avoid when

Range scans across keys
Plain modulo over physical servers (painful resharding)

Range sharding

Contiguous key ranges per shard (e.g. time or alphabetical).

Choose when

Range queries and time-series retention
Keys are naturally ordered

Avoid when

Monotonic keys concentrating new writes on one shard

Directory (lookup) sharding

A lookup table maps each key (or tenant) to a shard.

Choose when

Very uneven tenants (whales)
Moving individual tenants between shards
Data residency per region

Avoid when

You can't operate a highly available, cached directory

Don't shard yet

Vertical scaling, partitioning, caching, replicas, vertical splits.

Choose when

One primary can still handle writes with headroom
Team lacks capacity for a sharded architecture

Avoid when

Write volume or data size has outgrown the largest instance

Verdict

Shard only when a single primary can't keep up. Then choose the shard key your queries and transactions are scoped to, use hash sharding over many logical shards for even spread and easy rebalancing, add directory overrides for whales or residency, and use range sharding where range scans and retention dominate.

Hash vs Range vs Directory Sharding

Side by side

When to choose each

Hash sharding

Range sharding

Directory (lookup) sharding

Don't shard yet

Verdict

Learn more

Sources