Range Partitioning
Split ordered keyspace into contiguous ranges for efficient scans and controllable ownership.
2–5 minute refresher
ABC12345678
NodeKey
Add a node → move one slice, not every key.
Sorted keys → range boundaries → one owner per range
30second
refresher
refresher
Range partitioning assigns contiguous slices of an ordered keyspace to shards. It makes range scans and locality efficient, while requiring the system to split, move, and route around changing boundaries.
What problem does it solve?
Hashing spreads load but destroys natural order. Workloads that scan time, geography, tenant IDs, or adjacent keys need placement that preserves locality.
How it works
- Choose an ordered partition key.
- Maintain a map from boundary ranges to shard owners.
- Route point queries to one range and scans to overlapping ranges.
- Measure size and traffic independently for every range.
- Split large or busy ranges and merge small neighbors.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Large ranges | Small routing map | Coarse balancing and hot spots |
| Small ranges | Fine-grained movement | More metadata and coordination |
| Time-leading key | Efficient recent scans | Write hotspot at the newest range |
What happens if?
All writes target the latest timestamp
One terminal range becomes the sole write owner. Prefix with a controlled bucket, rotate ranges, or separate ingestion order from query order while preserving the scans the product needs.
Where it appears
- Bigtable tablets
- CockroachDB ranges
- HBase regions
- MongoDB range sharding
Senior interview modeWhen is range partitioning preferable to hash partitioning?Show answer
When ordered scans and data locality are primary access patterns and the system can actively split and balance skewed ranges.