Range vs hash partitioning — how do you choose, and what does each break?

🎤 Say this first

Range partitioning keeps keys in sorted order (shard A = users a–f, B = g–m …), which makes range scans and time-window queries cheap because they touch one or two shards. Its failure mode is skew and hotspots: partition by timestamp and every write goes to the newest shard, turning your cluster into one machine. Hash partitioning applies a hash to the key and distributes by the result, which spreads load beautifully — and destroys ordering, so a range scan becomes a scatter-gather across every shard. The usual production answer is a compound key: hash-partition on a high-cardinality prefix (tenant, user, device) and range-order within the partition — exactly Cassandra's partition key + clustering columns, and DynamoDB's partition key + sort key. You get spread across shards and locality within one.