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.