Range Partitioning and Key Space Management

1 of 8

3 related

How does a distributed database divide its key space so that range scans remain efficient? We chose range partitioning (not hash partitioning) because SQL databases need range scans for WHERE clauses, ORDER BY, and indexed lookups.

Each range maps to a set of nodes. CockroachDB starts with a single range covering the entire key space and splits as data grows past 512 MB per range.

“The control plane divides the full key space into contiguous, non-overlapping byte ranges.”

With 1M ranges at 512 MB each, the cluster holds ~512 TB of data. The key trade-off: range partitioning preserves key ordering for scans but creates hotspots on popular key prefixes.

Hash partitioning distributes evenly but destroys ordering. We accept the hotspot risk because the split/merge mechanism handles it: when a range gets too hot, the control plane splits it at the median key, distributing load across two nodes.

Google Spanner, TiDB, and YugabyteDB all use range partitioning for this reason.

Why it matters in interviews

Interviewers expect us to justify why range partitioning beats hash partitioning for a SQL database. Explaining the scan vs distribution trade-off and how splits handle hotspots proves we understand the design beyond surface level.

Related concepts

Next →Metadata Store (Raft-Based Consensus)