Hash Partitioning
Hash partitioning distributes rows across partitions by a hash of the partition key, so that writes spread evenly and a query on the key touches one partition without skew.
Definition
Hash partitioning is the strategy of assigning each row to partition hash(key) mod N, so that the rows are distributed evenly across partitions regardless of key value distribution, eliminating the skew that range partitioning suffers and enabling partition-pruning for equality predicates on the key.
Context and scope
Applied in distributed databases, sharded OLTP, and any store where even write distribution and point-query locality are the goals.
Common misconceptions
- Hash partitioning eliminates skew — it eliminates key-value skew; a single key that receives most traffic still concentrates on one partition
- Repartitioning is cheap — changing N rehashes every row; choose N with growth in mind or use consistent hashing to bound rehashing
Anti-patterns
- Hash partitioning on a key with a few hot values, so the hash spreads the keys but the traffic stays concentrated
- Choosing a partition count that will be too small in a year, forcing a repartition that rehashes the entire table
Related concepts
Authoritative source
https://www.postgresql.org/docs/current/ddl-partitioning.html
What it is
Hash partitioning is the strategy of assigning each row to partition hash(key) mod N, so that the rows are distributed evenly across partitions regardless of key value distribution, eliminating the skew that range partitioning suffers and enabling partition-pruning for equality predicates on the key. Applied in distributed databases, sharded OLTP, and any store where even write distribution and point-query locality are the goals. The data model and the access patterns are co-designed: a schema that is correct in the relational sense can be catastrophic for the queries the workload actually issues.
How it works
Indexing decisions follow the query shapes, not the column importance: a covering index turns a table scan into an index-only scan, but every index adds write amplification and storage cost. Partitioning aligns with the access dimension so a query touches one partition, not all. Transaction scope is minimized to hold locks briefly; long transactions are the root of contention and deadlock.
When to apply and pitfalls
Apply when data volume or query latency has a concrete business cost. The common pitfall is indexing for the current workload and ignoring the access patterns that growth will introduce — the index that helps today can serialize writes tomorrow. Another is treating the database as a black box, missing that the optimizer’s plan choice depends on statistics that drift as data changes.