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 field telemetry throughout, because the numbers are different when you are absorbing 10,000 points a second from a producing field rather than 1,000 inserts a second from a web app.

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

• Why autovacuum runs constantly on append-only tag tables where nothing is ever updated

• 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 dashboard measurably breaks your ingest SLA, and why that conversation is itself the signal

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