AWS cost · RDS right-sizing

Why RDS looks expensive - and how to right-size the instance

Someone posted that cloud databases are “incredibly expensive for small projects.” They had a 100 million row MySQL table, asked an AI assistant to price out RDS, and got quoted db.t4g.large at about $106/month. That number is real - but it answers the wrong question. The same database runs fine on db.t4g.small at about $23/month. Here is why the tier was wrong, and how to size RDS to what your queries actually use.

A low-traffic MySQL database usually runs fine on db.t4g.small at about $23/month, not the $100+ tier an AI or a rushed guess tends to suggest. RDS instance size follows your working set - the data your queries actually touch - not your total row count. Match the RAM to real usage and the bill drops fast.

How much should a small RDS database cost?

Here are the current on-demand prices for the burstable t4g family (us-east-1, Single-AZ, compute only - storage and I/O are billed on top):

For a small, low-traffic workload, the jump from t4g.small to t4g.large buys 6 GiB of RAM you never touch. That is about $83/month - roughly $1,000 a year - for headroom the database does not use.

Why did the AI quote 4x too much?

The AI was not broken. It anchored on the size of the table - 100 million rows sounds huge - and picked an instance to match that number. But row count does not decide how much RAM a database needs. A large table with selective queries and low traffic keeps only a small working set in memory at once. The mistake was not the tool; it was that nobody stopped to question the tier.

How do I pick the right RDS instance size?

Size the instance to your working set, not your row count. The working set is the slice of data your queries actually read - indexes and hot rows - which is usually far smaller than the full table. Two quick checks in CloudWatch tell you if you are over-provisioned: FreeableMemory that stays high, and CPUUtilization that stays low. If both are true, drop a tier and watch the same two metrics. Repeat until you have a comfortable margin, not a wasteful one. This pulls average free memory over a window you set - lots of headroom means the instance is oversized:

# average FreeableMemory over a chosen window (edit the dates)
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name FreeableMemory \
  --dimensions Name=DBInstanceIdentifier,Value=my-db \
  --start-time 2026-07-01T00:00:00Z \
  --end-time   2026-07-08T00:00:00Z \
  --period 3600 --statistics Average

When does it make sense to leave RDS?

Usually it does not. Right-sizing captures most of the savings while you keep managed backups, patching, and failover. If the instance is already the right size and steady, the next lever is a reserved instance, which discounts the compute you were going to run anyway. Moving to a self-managed database on a tiny instance can look cheaper on paper, but you take on the operational work RDS was doing for you.

Frequently asked questions

More AWS cost breakdowns