A method for right-sizing database instances that actually works

Quick answer

Size a database on four signals, not one. Check p95 CPU over 14 days (target 40 to 60 percent), buffer cache hit ratio (target above 99 percent for OLTP), freeable memory (should stay above 15 percent of instance RAM), and peak connection count against memory per connection. Downsize only when all four allow it. A database sitting at 12 percent p95 CPU with 45 percent freeable memory and a 99.8 percent cache hit ratio can safely drop two sizes: db.r6g.2xlarge to db.r6g.large takes it from $756 to $189 per month, a saving of $567. If CPU is low but freeable memory is under 10 percent, the instance is correctly sized and CPU is simply the wrong metric.

Right-sizing advice for databases usually reduces to "look at CPU and pick something smaller". That fails regularly, because most production databases are memory-bound, not CPU-bound. A database at 9 percent CPU may be perfectly sized: it is holding a large working set in the buffer pool, which is exactly what you paid for. Downsize it on the CPU number and you convert cached reads into disk reads, latency triples, and you end up buying provisioned IOPS to compensate at several times the saving.

The four signals

Signal	Healthy range	What it constrains
p95 CPU over 14 days	40 to 60 percent	Query execution capacity
Buffer cache hit ratio	above 99 percent (OLTP)	Memory adequacy for working set
Freeable memory	above 15 percent of RAM	Headroom for connections and sorts
Peak connections x per-connection memory	under 25 percent of RAM	Connection overhead

A downsize is safe only when all four permit it. Any single one being tight means the instance is doing something you have not accounted for.

Reading the signals together

Four combinations cover most real cases. Low CPU, high freeable memory, high cache hit ratio: genuinely oversized. Downsize confidently, usually by two steps. Low CPU, low freeable memory, high cache hit ratio: memory-bound and correctly sized. The CPU is idle because the data is in RAM, which is the point. Leave it alone, or consider a memory-optimized shape at a lower vCPU count if the family allows. High CPU, high freeable memory: CPU-bound, and often a sign of inefficient queries rather than insufficient hardware. Look at the top queries by total time before buying more vCPUs, because a missing index is far cheaper to add than a larger instance. Low CPU, high freeable memory, low cache hit ratio: something is scanning cold data, usually a batch job or a reporting query. Move that workload rather than sizing production around it.

A worked example

A db.r6g.2xlarge (8 vCPU, 64 GB, about $756 per month in us-east-1) shows p95 CPU of 12 percent, freeable memory averaging 29 GB (45 percent), buffer cache hit ratio of 99.8 percent, and peak connections of 60 using roughly 500 MB total. Every signal says oversized.

Candidate	vCPU / RAM	Monthly	Projected p95 CPU	Projected free memory
db.r6g.2xlarge (current)	8 / 64 GB	$756	12%	29 GB
db.r6g.xlarge	4 / 32 GB	$378	24%	about 10 GB
db.r6g.large	2 / 16 GB	$189	48%	about 2 GB
db.m6g.xlarge	4 / 16 GB	$226	24%	about 2 GB

db.r6g.large projects to 48 percent CPU, inside the healthy band, but only 2 GB free, which is tight for sort operations and index maintenance. db.r6g.xlarge at $378 projects to 24 percent CPU and 10 GB free, which is comfortable. Take the one-step move, save $378 per month, and re-evaluate in a month with real data rather than making a two-step jump on projections.

That incrementalism matters. Downsizing is a restart on most managed services, so each move costs a maintenance window. Two careful moves a month apart cost two windows; one aggressive move that has to be reverted costs two windows plus an incident.

The signals people forget

Burstable instances have a CPU credit balance, and a t3 or t4g database that has exhausted its credits is throttled regardless of what the CPU graph suggests. Always check CPUCreditBalance before concluding a burstable instance has headroom, and remember that unlimited mode bills surplus credits at about $0.05 per vCPU-hour, which can quietly exceed the cost of the next fixed-performance size up.

Storage-attached throughput limits are instance-specific. Moving from db.r6g.2xlarge to db.r6g.large cuts maximum EBS bandwidth substantially, so a database that looked I/O-comfortable on the larger shape can become throughput-limited on the smaller one even though the volume configuration did not change. Check the instance family's EBS bandwidth figures, not just vCPU and RAM.

And check what else the instance does at month end. A database at 15 percent CPU for 28 days and 85 percent for two days of reporting is sized for those two days. Either accept the sizing, move the reporting to a replica, or schedule a temporary scale-up around the window.

Make it repeatable

Right-sizing is not a project, it is a quarterly review. Pull the four signals for every database into one table, sort by projected saving, and act on the top five. A fleet of thirty databases reviewed this way typically yields 20 to 35 percent savings on the first pass, because instances are almost always sized for a launch-day estimate that nobody revisited.

Price candidate shapes from Terraform before the maintenance window so the saving is known in advance. Compare instance families against the resource catalog, and see right-sizing against performance for the performance-side view.

FAQ

Why is CPU utilization a bad sizing signal for databases?

Because most production databases are memory-bound, not CPU-bound. A database at 9 percent CPU may be perfectly sized, holding a large working set in the buffer pool, which is what you paid for. Downsizing on CPU alone converts cached reads into disk reads, triples latency, and often forces you to buy provisioned IOPS at several times the compute saving.

What signals should I use to right-size a database?

Four together: p95 CPU over 14 days (healthy at 40 to 60 percent), buffer cache hit ratio (above 99 percent for OLTP), freeable memory (above 15 percent of instance RAM), and peak connections times per-connection memory (under 25 percent of RAM). Downsize only when all four permit it. Any one being tight means the instance is doing something the others do not show.

What does low CPU with low freeable memory mean?

The instance is memory-bound and correctly sized. CPU is idle precisely because the working set sits in RAM and queries are not hitting disk. Leave the size alone, or consider a memory-optimized family at a lower vCPU count if one fits. This is the combination most often misread as waste, and downsizing it is how right-sizing exercises cause incidents.

How much can right-sizing save?

A db.r6g.2xlarge at $756 per month showing 12 percent p95 CPU, 45 percent freeable memory, and a 99.8 percent cache hit ratio can safely drop to db.r6g.xlarge at $378, saving $378 per month. Across a fleet of thirty databases, a first structured pass typically yields 20 to 35 percent savings because instances were sized for a launch-day estimate nobody revisited.

What do people forget when downsizing a database?

Three things: burstable instances can be throttled on an exhausted CPU credit balance regardless of the CPU graph, and unlimited mode bills surplus credits at about $0.05 per vCPU-hour; EBS bandwidth limits are instance-specific, so a smaller shape can become throughput-limited with an unchanged volume; and month-end reporting peaks may be what the instance is actually sized for.

How does C3X help right-size databases?

C3X prices candidate instance shapes from Terraform before the maintenance window, so the saving from a proposed downsize is known in advance and the change is reviewed as a cost decision. Since downsizing requires a restart on most managed services, knowing the exact figure for each candidate shape lets you pick the right single step rather than guessing and reverting.

What to do next

Know the saving before you take the maintenance window. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.