Database rightsizing advisor for teams stuck on oversized instances

The specific moment: an engineer inherits a production database that's been running on the same instance class for two years. Nobody knows if the original sizing was right. The monthly bill is painful but changing the instance size feels risky — what if the current size is actually needed? So nothing changes, the bill keeps coming, and the complaint is exactly what users describe: 'I feel it is costing us too much' and 'it is a bit costly, considering it is billed for the whole time it is up.'

Incumbent vendors don't solve this because their recommendation engines (like AWS Trusted Advisor or RDS recommendations) operate at the service level and are deliberately conservative — they'd rather you pay for headroom than blame them for a performance incident after following their advice. The suggestions they do make are generic ('consider a smaller instance class') with no simulation of what actually happens to query latency at the new size for your specific workload.

What's missing is a tool that takes historical CPU, memory, IOPS, and connection count data from a running RDS or Aurora instance, models what would happen to P95 query latency if you dropped one instance tier, and gives an engineer enough confidence to actually make the change — or points to the one metric that's the real constraint, so they know why they can't downsize yet.

This is a business because rightsizing is not a one-time event. Databases grow, workload patterns shift seasonally, read replicas get added and forgotten, and every time the team grows or the product changes, the sizing question resurfaces. The cost of doing nothing is quantifiable: a team running an r6g.2xlarge when they need an r6g.large is overpaying by several hundred dollars a month, compounding across every database instance they run.

What to build

Pull 90 days of CloudWatch metrics from a team's RDS and Aurora instances, build a per-instance rightsizing recommendation with a simulated cost comparison and an explicit statement of the constraining resource (CPU, memory, or IOPS), and deliver it as a report engineers can share with a manager to justify the change.

Where to start

Offer a free one-time rightsizing report for a single RDS instance in exchange for a case study — this gets you real workload data to calibrate the model, gives the customer a concrete dollar figure they can act on, and creates a natural expansion conversation for the rest of their fleet.

The hard part

The hardest early problem is calibrating confidence thresholds — if your first recommendation causes even one performance incident after a downsize, word spreads and the product is seen as dangerous; getting this right requires enough historical data from diverse workloads that you can't fully validate it until you have paying customers.

How it makes money

Charge per instance per month for continuous monitoring and re-evaluation as workloads change, with a minimum of five instances — below that the savings don't justify the overhead for either party.