Partition Hotspot Amplification
Sequential or low-cardinality partition keys concentrate writes on a single partition or shard, creating a hotspot. The hot partition absorbs disproportionate I/O, CPU, and memory pressure while other partitions sit idle. As load grows, the hotspot becomes a hard throughput ceiling for the entire table or topic.
Partitioned PostgreSQL table or Kafka topic with sequential key pattern
Degradation Replay
Nominal: Even Distribution
Write load evenly distributed across partitions
- ·Partition sizes within 10% of each other
- ·No single partition consuming >30% of total table I/O
- ·All partition host nodes at similar load
- ·Buffer cache pages evenly spread across partitions
- !All partitions serving reads and writes at equal throughput
Operational simulation model only, not a production forecast. Degradation stages are derived from structured operational knowledge, not measured telemetry. Do not use for capacity planning or incident response.
Run With Your Parameters
Adjust the parameters below to see how metric values shift across degradation stages. Formulas are deterministic: same inputs always produce the same output.
Simulation Parameters
Fraction of traffic hitting the hottest partition
Computed Degradation Stages
Write load evenly distributed across partitions
Sequential insert pattern emerging: all new rows targeting last partition
Hot partition host I/O utilization exceeds 75%; write queue forming
Hot partition I/O saturated; all writes queuing behind disk bottleneck
Threshold Events
Hot partition receiving 1,600 RPS (3.2× balanced expectation). Balanced load would be 500 RPS per partition.
Interpretation
40% of traffic (10,000 RPS) concentrates on one partition. Hot partition receives 3.2× balanced load. Connection pool: 44%.
Traffic skew 3.2× exceeds partition capacity: hot shard saturation
Re-key the hot partition using a high-cardinality composite key. Add a dedicated read replica for the hot partition. Consider hash-range hybrid partitioning to redistribute hot key space.
Parameterized simulation: not a production forecast. Values derived from deterministic formulas applied to your parameters. Do not use for capacity planning or operational decisions without validation.
Propagation Model
I/O and CPU pressure concentrates on partition host; buffer cache fills with hot partition pages, evicting other data
Stabilizes: Stabilizes only when write load is redistributed via key salting or repartitioning
Hot partition IOPS reaches disk throughput limit; writes begin queuing behind I/O bottleneck
Stabilizes: No stabilization possible without architectural change: throughput ceiling is hard
Range queries on sequential key require full hot-partition scans; query planner estimates stale for hot partition
Stabilizes: Resolved by ANALYZE + histogram updates
Recovery Patterns
Key salting for new writes
Immediate for new writes; existing data remains imbalanced until repartitioned- ·Range queries on salted key require scatter-gather across all salt buckets
- ·Application must understand salt prefix for direct lookups
- !Historical data remains on original partition: read hotspot persists for old data queries
Full table repartitioning
Hours to days depending on table size; requires online DDL or pg_partman- ·Requires downtime or dual-write during migration
- ·Temporary storage overhead for parallel partition structure
- !New partition key must be validated against all query patterns: poor choice creates new hotspot
Operational Summary
Partition hotspots arise from poor key choice: sequential, low-cardinality, or monotonically increasing keys concentrate writes on one partition. This creates a hard throughput ceiling that cannot be resolved by vertical scaling or adding more instances. The fix requires redistributing the key space, which is a significant operational undertaking on large tables.