Continuous query tuning advisor for AWS RDS teams

The moment a DBA or backend engineer notices their p95 latency creeping up, they open the native console and find aggregate graphs with no actionable path forward. They know something is wrong — 'sometimes performance gets crazy' — but diagnosing whether it is a bad query plan, a connection pool ceiling, an undersized instance, or noisy-neighbor I/O contention requires jumping between five different panels and making educated guesses.

The gap persists because AWS has no structural incentive to make tuning so easy that you stop scaling up. The most visible 'fix' in the console is the button that makes the instance bigger. Users literally complain 'memory usage is easily fixed by scaling up' — that is not a satisfied user, that is a user who gave up on tuning and paid more. The vendor's revenue goes up when you scale, not when you optimize.

Existing observability products surface metrics but stop short of telling you what to actually change. They show you that slow queries are happening; they do not tell you that adding a composite index on two specific columns would cut that query's cost by 80%, or that your autovacuum settings are causing checkpoint storms on write-heavy tables. Users ask for 'slow query detection and IOPS logging' together — they want correlation, not dashboards.

This is a recurring business because query patterns change with every schema migration, every traffic spike, every new feature release. It is not a one-time audit. A team that ships code weekly generates new performance problems weekly. Without something that watches continuously and flags specific regressions with a recommended action, the engineer is back to manual investigation every single time — which at a company doing 1000 TPS costs real engineering hours every month.

What to build

Connect to a customer's RDS or Aurora instance via read replica or query log export, continuously fingerprint slow query patterns, correlate them with IOPS and CPU metrics, and surface a ranked list of specific index, config, or instance-sizing recommendations with estimated impact — refreshed every time query patterns shift.

Where to start

Start exclusively with Aurora MySQL teams using Performance Insights already enabled — they have the data pipeline partially built and the pain is loudest there, so recommendations can be specific and validated quickly without needing to instrument anything new.

The hard part

Getting read access to production query logs without requiring customers to change security group rules or grant dangerous IAM permissions — the first onboarding step will lose half your trials if it is not nearly zero-friction.

How it makes money

Monthly subscription per RDS cluster monitored, starting around $150/cluster/month, with a free tier for a single small instance to let engineers prove value before bringing it to their manager.