Abstract

Every database has bad days. A slow query after a schema change. Replication lag during a spike. An autovacuum job that runs long enough to make you nervous. Those are tuning problems, they have tuning solutions, and a senior engineer fixes them in an afternoon.

There is a second category. The kind where every fix creates the need for the next fix, where performance degrades not because of one bad query but because the workload has grown into territory the database was never designed for. Teams burn two quarters optimizing their way around this before realizing the optimization was the trap.

This session is a diagnostic. Five signs, each with a specific measurement you can take. Count how many apply to your system and you get a straight answer about whether you have a tuning problem or an architectural one.

We frame it for energy telemetry throughout, because the numbers are different when you are absorbing 10,000 points a second from a charging network or a storage fleet, holding it for a multi-year compliance window, and serving a portfolio dashboard off the same tables.

What you'll learn

• The difference between optimization that is cumulative and optimization that is cyclical, and how to check which one you are doing by looking at your sprint backlog

• How to test whether your slowest queries are scan-bound, and what it means if execution time tracks the time range linearly

• The point at which adding an index to help a fleet dashboard measurably breaks your ingest SLA, and why that conversation is itself the signal

• What to do at each score band, and why a score of four or five does not mean leaving Postgres

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