Abstract

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

Energy fleets are unusually good at producing this. Teams partition by the column they already filter on, which means site_id, charger_id, or asset_id. But the assets are not comparable. One utility-scale battery site emits more telemetry in an hour than a hundred rooftop inverters emit in a day. One DC fast charging hub off an interstate generates the write volume of an entire portfolio of workplace L2 chargers. The schema looks correct. Storage looks balanced. Then p95 write latency drifts from 8ms to 25ms over six weeks and every other metric reads healthy.

This session shows you how to find it and fix it. We run the diagnostic against a partitioned asset telemetry table, identify the hot partition by dead tuple ratio and index bloat, and then walk through two schema-level fixes. You leave with queries you can run against your own largest table today.

What you'll learn

• Why heterogeneous fleets make asset-based partition keys skewed by construction, not by accident

• 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

Can’t make it live? Register anyway and we’ll send you the recording.