Database Sharding Strategies: Range, Hash, and Directory-Based, Explained

A single database server has a ceiling: storage capacity, and write throughput a single primary can absorb. Read replicas push that ceiling back by copying the same data to more machines for reads, but every replica still holds the entire dataset and still funnels through one primary for writes. Sharding is what you reach for when that ceiling is the actual constraint, not read load, and it works by splitting the data itself, not copying it.

The strategy you pick determines whether the result scales cleanly or creates a new bottleneck shaped exactly like the old one.

Hash-based sharding: even distribution, expensive ranges

Hash-based sharding applies a hash function to the shard key, usually a user ID or tenant ID, and routes the row to hash(key) % number_of_shards.

function getShardForUser(userId, shardCount) {
  const hash = hashFunction(userId); // e.g. a consistent hash, not just userId itself
  return hash % shardCount;
}

// user 8821 and user 8822 can land on completely different shards,
// even though their IDs are sequential

Because a well-chosen hash function distributes values close to uniformly, rows spread evenly across shards regardless of any natural clustering in the source data. No single shard ends up disproportionately large or busy just because a lot of users signed up in the same week.

The cost shows up on range queries. “Give me all orders from users 8000 to 9000” now has to query every shard, since the hash scattered those sequential user IDs randomly across the cluster, then merge the results in application code. If your access patterns are almost entirely single-key lookups (fetch this user’s data, fetch this order), hash-based sharding’s even distribution is close to a pure win. If range scans over the shard key are common, it’s a real tax on every one of them.

Range-based sharding: fast ranges, hot-spot risk

Range-based sharding assigns each shard a contiguous range of the shard key’s values, commonly a time range.

Shard 1: orders created 2026-01-01 to 2026-03-31
Shard 2: orders created 2026-04-01 to 2026-06-30
Shard 3: orders created 2026-07-01 to 2026-09-30

Range queries over the shard key become fast and cheap, since a query for “orders from Q2” hits exactly one shard instead of fanning out to all of them. This is the natural fit for time-series data, logs, orders, events, where “give me the recent window” is the dominant query pattern.

The risk is concentration. If new writes always land in the newest range, which is the common case for time-based sharding, one shard absorbs effectively all current write traffic while older shards sit nearly idle. You’ve distributed the data across machines, but not the load, which defeats a large part of the original point. Mitigating this usually means either sizing ranges by expected volume rather than fixed calendar periods, or accepting that the current-period shard needs to be provisioned for peak write throughput regardless of how many other shards exist.

Directory-based sharding: a lookup layer, and real flexibility

Directory-based sharding replaces the algorithmic mapping (a hash or a range boundary) with an explicit lookup: a separate table or service that records which shard holds which key.

// A lookup service, itself needs to be fast and highly available
async function getShardForTenant(tenantId) {
  return shardDirectory.lookup(tenantId); // returns e.g. "shard-7"
}

// Moving a specific tenant to its own shard is just an update to the directory,
// no rehashing, no range boundary change for anyone else
await shardDirectory.reassign('tenant-4471', 'shard-12-dedicated');

The payoff is real operational flexibility. A single noisy tenant hammering shared infrastructure can be moved to a dedicated shard by updating one directory entry, without touching the hash function or range boundaries that every other key’s placement depends on. This matters a lot for multi-tenant SaaS, where load is rarely evenly distributed across tenants and the biggest customer is often disproportionately the busiest one.

The cost is an extra network hop on every query (the directory lookup itself) and a new critical-path component: if the directory service is slow or unavailable, every sharded query is blocked behind it, so it needs its own high-availability story, typically a small, heavily-cached, aggressively-replicated dataset since it’s just key-to-shard mappings.

Comparing the three

	Hash-based	Range-based	Directory-based
Distribution	Even, by design	Depends on key distribution over ranges	Whatever the directory assigns
Range queries	Expensive, fans out to all shards	Cheap, hits one shard	Depends on underlying scheme
Hot-spot risk	Low	High if writes concentrate on one range	Low, individual keys can be rebalanced
Resharding	Requires rehashing most keys	Requires redrawing range boundaries	Update directory entries, more surgical
Extra infrastructure	None beyond the hash function	None beyond range config	A directory service that must be fast and available

Reach for sharding last, not first

Sharding is usually the wrong first move. Read replicas solve read-heavy load without touching how data is stored. Caching and query optimization solve a large share of what looks like a capacity problem but is actually an inefficient-query problem. Vertical scaling, a bigger single machine, buys real headroom before it hits diminishing returns.

Sharding earns its complexity specifically when data volume exceeds what one machine can store, or write throughput exceeds what a single primary can absorb, regardless of hardware. Once you’re actually there, resharding a live system without downtime, moving data between shards while queries keep running against it, is genuinely one of the harder operations in distributed systems engineering. Pick the strategy that matches your actual query patterns up front, because migrating from hash-based to range-based sharding after the fact means rebuilding the same painful process you were trying to avoid by sharding in the first place.