When our database started throwing high CPU alerts and queries slowed to a crawl, I realized we had been treating infrastructure costs as a billing problem when it was actually a code problem.
The instinct is to scale up. Bigger instance, more memory, problem solved. But that just masks the real issue and inflates your AWS bill every month. The actual fix required going deeper into what the database was doing, not just how much horsepower it had.
We started with AWS RDS Performance Insights, which turned out to be the most useful tool I had underused for way too long. It surfaces which SQL statements are consuming the most CPU, broken down by wait types and execution frequency. Within an hour of digging in, we had a short list of offending queries that were responsible for the majority of the load.
Here is what the investigation process looked like in practice:
• Pull the top SQL statements by CPU consumption from Performance Insights, sorted by load over the last 24 hours
• Cross-reference those statements against your codebase to find the originating calls
• Check whether missing or unused indexes are the culprit before touching query logic
• Look at execution plans for the worst offenders to understand full table scans or inefficient joins
• Correlate CPU spikes on the metrics timeline with specific application events or batch jobs
The pattern we kept seeing was not exotic. It was the same handful of issues: queries running without proper indexes, N+1 patterns that looked fine in development but fell apart under real data volume, and a few places where we were pulling far more columns than we actually needed.
What surprised me was the ratio. Once we fixed the top five query issues, CPU usage dropped significantly without touching the instance type at all. This lines up with something I have come to believe more firmly after this exercise: roughly 80 percent of infrastructure optimization is a code problem, not a hardware problem. Throwing compute at it delays the reckoning but does not resolve it.
The instance specifications still matter. You need to understand your baseline and what your workload profile looks like. But the instance is a ceiling, not a solution. The real leverage is in what you are asking the database to do.
Key takeaways from going through this process:
• RDS Performance Insights is free for the last 7 days of data and gives you query-level visibility that CloudWatch alone cannot
• Start with the highest CPU consumers, not the slowest individual queries — they are often different lists
• Index analysis should come before any query rewrite — it is faster and lower risk
• Correlating metric spikes with application events saves hours of guessing
• Scaling up without diagnosing first means you will hit the same ceiling again, just later and at higher cost
The next step for us is setting up automated slow query logging with thresholds so we catch regressions before they compound. Performance tuning is not a one-time fix — it needs to be part of the regular development feedback loop.
If you have gone through a similar performance investigation, what tooling or process changes made the biggest difference for your team?
Top comments (0)