Abstract

At 50,000 inserts per second, a skewed partition key can route 40,000 of them into one partition. That partition throttles your whole write path while the other 199 sit idle.

Nothing about the setup looks wrong. You partition by the column you already filter on, which in oilfield platforms means well_id, pad_id, or asset_id. The schema is correct. Storage looks balanced. Six weeks later p95 write latency has drifted from 8ms to 25ms and every other metric still reads healthy.

We run the diagnostic against a partitioned tag table, find the hot partition by dead tuple ratio and index bloat, then look at the two ways out. One is to repartition by time and build the automation to manage it yourself. The other is to stop picking a partition key at all and let the database handle chunking. If you already run TimescaleDB hypertables, this is a problem you don't have, and we'll show you why.

What you'll learn

• Why a skewed partition key does more damage than a missing index, and why it stays invisible until the damage is done

• How write concentration compounds through index page splits, WAL volume, and per-partition autovacuum that has no idea it is being starved

• How to move from value-based to time-based range partitioning, and what the migration path looks like above and below 100 million rows

• How hypertables handle chunk creation, compression, and lifecycle without external cron jobs, and what that does to WAL throughput