When splitting a table's rows across independent database servers, the placement function can either hash the chosen key or assign contiguous ranges of it. Compare hash-based and range-based placement, and say which workloads suit each.

## The two placement functions Once you have picked a shard key, something must turn a key value into a shard number. There are two mainstream answers. **Hash placement**: `shard = f(hash(key))`. The hash deliberately destroys any meaning in the key so that adjacent values land far apart. Almost nobody uses raw `hash(key) % N` in production, because increasing `N` from 8 to 9 remaps roughly 8/9 of all rows. Instead the hash space is cut into a large fixed number of **virtual buckets** (say 4096 or a consistent-hashing ring), buckets are assigned to physical shards, and growing the cluster moves whole buckets. The mapping stays stable; only the bucket→shard table changes. **Range placement**: shard 1 holds keys `[a, m)`, shard 2 holds `[m, s)`, and so on. Boundaries are metadata, stored in a routing table or a coordinator, and can be edited: a range that grows too big or too hot is split at its midpoint into two ranges that can live on different servers. ## Distribution and hotspots Hashing gives you uniformity for free. It does not care whether your key is an auto-increment integer, a UUID, an email address or a timestamp — the output is close to uniform, so rows and, usually, load spread evenly. This is its dominant virtue, and it is why hash placement is the default in Citus's `create_distributed_table`, in Vitess's default hash vindex, and in most home-grown shard layers. Hashing does **not** protect you from *value* skew: if 30% of your rows carry `tenant_id = 42`, hashing puts 100% of those rows on one shard, because the same key always hashes the same way. Hashing fixes *sequential* skew, not *frequency* skew. Range placement inherits whatever shape the key has. That is fatal for monotonic keys: with ranges on `created_at` or on an auto-increment id, every new row lands in the topmost range, so exactly one shard takes all inserts while the rest serve cold history. It is fine — even ideal — for keys whose density is roughly known and stable, or for systems that continuously split and move ranges automatically. ## Query shapes This is where the two diverge most sharply. With range placement, a predicate like `key BETWEEN x AND y` maps to a contiguous span of ranges, so the router touches only the shards that can possibly contain matches, and each shard returns its rows already ordered — a merge of a few sorted streams. Ordered pagination, time-window queries and prefix scans are all cheap. With hash placement, the same predicate is unanswerable without asking every shard, because logically adjacent keys are physically scattered. Only **equality** on the shard key (or `IN` on a small list) prunes. Ordered pagination becomes a global sort across a scatter-gather result. Both handle point lookups on the shard key equally well. ## Rebalancing and elasticity Range systems rebalance by splitting a range at a chosen point and handing half to another node; the split is local, cheap, and can be triggered automatically by size or heat. This makes range placement attractive for systems that must absorb unpredictable growth without a human deciding shard counts. Hash systems rebalance by moving virtual buckets. That works and is well understood, but a single hot **key** cannot be split at all — its bucket is atomic, and every row with that key is on one shard by definition. If one tenant outgrows a machine under hash placement, your only options are to give it a dedicated shard, or to change the key (for example to a composite `(tenant_id, sub_id)` hash) and move data. ## Composite and layered schemes Real systems mix the two. A common pattern is hash on the tenant, range on time *within* the shard's local table partitioning — you get even tenant spread across servers and cheap time-window pruning and retention inside each server. Another is a two-level scheme: hash placement for the physical bucket, with an explicit directory that can override placement for a handful of outsized keys. ## Choosing Ask two questions. *Is the shard key monotonic?* If yes, range placement will hotspot on writes and you want hashing (or a deliberately randomised prefix). *Do queries scan ordered ranges of the key?* If yes, hashing turns your main access path into a fan-out and you want ranges. For the classic OLTP multi-tenant workload — point and small-set access by tenant, no ordered scans across tenants — hash on tenant id is almost always right. For time-series or log-shaped data queried by window, range on time is natural, with the standing caveat that the newest range is the write hotspot and needs a plan (more granular ranges, a salted prefix, or accepting that the hot range gets its own hardware). ## How to answer Name both functions, give the one-line strength and the one-line failure of each (hash: uniform but no ordered pruning; range: ordered and splittable but hotspots on monotonic keys), then pick one for a stated workload and say what you would monitor to know you were wrong.