Right-sizing databases: matching the instance to the load
Databases are often the biggest single line on the bill and the most over-provisioned, sized for a peak that rarely comes or copied from another environment. Right-sizing to real CPU, memory, and IO need cuts cost without hurting performance. Here is how.
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.
Related posts
- A method for right-sizing database instances that actually works
CPU utilization alone is a bad sizing signal for databases, because the binding constraint is usually memory or connections. Here is a four-signal method that produces a defensible instance choice instead of a guess.
- The two week right-sizing sprint: a repeatable playbook
Right-sizing stalls when it becomes a permanent backlog. Running it as a time boxed sprint with a ranked list, a batch cadence, and a rollback rule ships 30 to 60 resources in two weeks. Here is the sprint plan.
- ElastiCache node sizing: paying for the right amount of memory
ElastiCache (Redis and Memcached) is priced per node by instance type, so node sizing and count drive the bill. Oversized memory, too many replicas, and the wrong node family are the common overspends. Here is how to size for cost.
- Right-size RDS instances guide: databases without the bloat
RDS instances are often provisioned larger than the workload needs, and unlike stateless compute, resizing a database takes care. Here is how to right-size RDS instance class, storage, and IOPS to real usage without risking the database.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.