Range vs hash partitioning

Partitioning (sharding) splits data across machines so each stores and serves a slice. A partition key decides where each record lives, and the function from key to partition comes in two main forms.

#Range partitioning

Each partition owns a contiguous range of keys: a–f, g–m, and so on. Used by HBase, Bigtable, CockroachDB, TiDB and MongoDB's ranged sharding.

• Range scans are efficient: keys are sorted, so "all events between 10:00 and 10:05" touches one or two partitions.
• Partitions split and merge as they grow and shrink, adapting to the data.
• Sequential keys create hot spots: with timestamps or auto-increment IDs, every new write goes to the last range.

#Hash partitioning

Hash the key and assign by hash value. Used by Cassandra, DynamoDB and Redis Cluster.

• Even load: similar keys land on different partitions, so sequential keys spread out.
• No range scans across keys: adjacent keys are scattered; range queries must ask every partition.

#Compound keys: both at once

Hash the first part of the key to pick the partition and sort by the second part within it. In Cassandra, PRIMARY KEY ((user_id), created_at) keeps all of a user's rows together, ordered by time — so "a user's latest posts" is one sequential read, while users spread evenly across the cluster.

#Choosing the key

The key matters more than the scheme:

• Pick the field almost every query filters by (tenant_id, user_id, conversation_id), so queries touch one partition.
• Avoid low-cardinality keys (country, status) — you'll have a few enormous partitions.
• Watch for skew: one huge tenant or celebrity makes a hot partition whatever the scheme.

Never assign hash partitions with hash(key) mod N: changing N moves almost every key. Use consistent hashing or a fixed number of partitions mapped to nodes. See also secondary indexes on sharded data.