Database cost auditing for AWS and managed Postgres/MySQL teams

The moment that drives this: an engineering team gets a monthly cloud bill that's 40% higher than last month, and nobody can trace which database instance, configuration choice, or query pattern caused it. They open the cloud console, see line items by service, and have no path from 'this is expensive' to 'here is what to change.'

The gap persists because the cloud providers and managed database vendors have a structural incentive not to make spending visible — every dollar you don't notice is a dollar you keep paying. Their billing consoles are designed around their internal cost categories (storage IOPS, data transfer, instance hours), not around the engineering decisions that drive those costs. The buyer of the cloud account is often a finance or DevOps lead, while the person making configuration choices is a backend engineer — neither one owns the problem clearly enough to push for better tooling.

Users complain that 'pricing is difficult to work or budget with' and that costs are hard to estimate, especially that 'powerful instances are a little bit expensive' and 'prices can work out expensive, so watch your settings while setting up.' That last complaint is the real tell: users know misconfiguration costs them money but get no signal during setup, only on the next bill.

This is a business and not a feature because the need recurs every billing cycle, it compounds as teams add databases, and the cost of doing nothing is concrete — teams overpay by 20-40% on idle or misconfigured database resources routinely. Cloud cost tools exist but they operate at the service level, not at the database configuration level: they'll tell you Aurora cost $3,200 this month but won't tell you that your RDS instance class is sized for peak load that never materialises, or that your Aiven plan includes read replicas you haven't used in 90 days.

What to build

Connect to AWS Cost Explorer, RDS/Aurora APIs, and Aiven APIs to pull actual instance config, usage metrics, and billing data, then surface per-database recommendations ranked by estimated monthly savings — with enough specificity that an engineer can act on them without leaving the tool.

Where to start

Start with teams running RDS exclusively — it's the largest base, the billing model is well-documented, and the gap between instance class and actual CPU/memory utilisation is measurable from CloudWatch without any special access, which means you can show value before a customer shares credentials.

The hard part

Getting meaningful API access and mapping cost data to configuration decisions requires handling edge cases across multiple providers simultaneously — Aurora pricing differs enough from RDS that a single recommendation engine will give wrong advice until you've handled both correctly, which means your first customer will hit a bad recommendation before you've earned trust.

How it makes money

Monthly subscription priced as a percentage of identified savings (e.g. 10-15% of the first month's confirmed savings), capped at a flat fee once savings exceed a threshold — aligns incentives and makes the ROI conversation easy.