Right-sizing databases: matching the instance to the load

Quick answer

Databases are often the largest and most over-provisioned line on the bill, sized for an imagined peak or copied from another environment. Right-size to real CPU, memory, IO, and connections, using observed peak percentiles plus margin, and lean on indexing, caching, and pooling first so the instance you need is smaller. Cut cost without hurting performance by fixing the workload, then the size.

The database is frequently the single most expensive resource in an architecture, and frequently the most over-provisioned. It gets sized generously out of caution, copied from production into every environment, and rarely revisited. Right-sizing it, carefully, is one of the largest cost savings available, but databases are less forgiving than stateless compute, so it takes more care.

Size to real usage, not fear

Look at actual CPU, memory, IO, and connection usage at peak (observed p95 or p99, not averages) rather than the size someone picked at launch. A database idling at 15% CPU with gigabytes of unused memory is paying for capacity it does not use. Match the instance class to real peak plus a safety margin, the same discipline as rightsizing without hurting performance, applied to the most sensitive resource.

Fix the workload before the size

Lever	Effect on required size
Indexing	Cuts CPU and IO per query
Caching	Deflects reads from the database
Connection pooling	Frees memory held by idle connections
Query tuning	Reduces expensive scans

Often the database is large because the workload is inefficient. Indexing, caching, and connection pooling each reduce the load the database must handle, which lets a smaller instance serve the same traffic. Fix the workload first, then the instance you need is smaller.

Storage, IO, and environments

Right-size storage type and provisioned IOPS too, since over-provisioned IOPS is common and expensive. Use smaller instances and single-AZ in non-production rather than copying production sizing, and apply reservations to the steady production database once it is correctly sized, so you discount the right size rather than committing to an oversized one.

FAQ

How do I right-size a database?

Look at actual peak CPU, memory, IO, and connection usage (observed p95 or p99, not averages) and match the instance class to real peak plus a safety margin. Fix workload inefficiencies with indexing, caching, and pooling first, so the instance you need is smaller.

Why are databases often over-provisioned?

They get sized generously out of caution at launch, copied from production into every environment, and rarely revisited. A database idling at low CPU with unused memory is paying for capacity it does not use, which is common and expensive since the database is often the biggest line.

How do I reduce database cost without hurting performance?

Fix the workload before the size: index frequent queries to cut CPU and IO, cache to deflect reads, and pool connections to free memory. Then right-size the instance, storage type, and provisioned IOPS to real peak usage, and use smaller instances in non-production.

Should I fix queries or scale the database?

Fix queries first. Indexing, caching, connection pooling, and query tuning reduce the load the database handles, which lets a smaller, cheaper instance serve the same traffic. Scaling up to brute-force an inefficient workload pays for capacity that better queries would not need.

Do I need to right-size database storage too?

Yes. Storage type and provisioned IOPS are commonly over-provisioned and expensive. Match the storage tier and IOPS to real IO needs, and avoid provisioning high IOPS the workload never uses, which is a frequent and easily-missed database cost.

Does C3X estimate database cost?

C3X prices your database instances, storage, and provisioned IOPS from your Terraform, so you can compare instance sizes and configurations before deploy. Right-sizing to real usage, informed by observed load, is what turns that estimate into a saving.

What to do next

Compare database sizes before you deploy. C3X reads your Terraform and prices your database and the rest of your stack against a live catalog. Start with the quickstart.