Database cost comes down through a handful of levers, each hitting one pricing dimension: the instance class, the storage type and provisioned performance, how I/O is billed, running time, backup retention, the number of copies and the age of the engine's major version. Some of these decisions can only be reversed with a migration or downtime. Managed databases covers the pricing dimensions, reserved capacity the commitments.
How it works
| Lever | What it lowers | What limits it |
|---|---|---|
| Smaller instance class, newer generation | instance hours, several times over with Multi-AZ and replicas | memory and I/O needs, restarts, reservations tied to an instance class type |
| Storage type and provisioned IOPS | storage and IOPS | storage grows easily and shrinks with difficulty |
| Aurora I/O configuration | I/O charges, or higher instance and storage rates | switching freely in one direction only |
| Serverless with pause, stopping | compute during idle periods | resume time, maximum stop duration |
| Backup retention and snapshots | backup storage | recovery requirements |
| Replicas and test copies | additional instances and storage | read and availability needs |
| Engine upgrade | Extended Support surcharges | testing the new major version |
Rightsizing follows the logic for instances; the providers' tools apply their own rules.
AWS
AWS Compute Optimizer recommends instance classes and storage for RDS for MySQL, RDS for PostgreSQL and Aurora: volume type and IOPS for RDS, and for Aurora the storage configuration with estimated instance, storage and I/O cost; on request it also shows Graviton instances. On gp3, RDS provides a baseline of 3,000 IOPS and 125 MiB/s, and for Db2, MariaDB, MySQL and PostgreSQL from 400 GiB (Oracle from 200 GiB) 12,000 IOPS and 500 MiB/s; except on SQL Server, additional IOPS and throughput can only be provisioned from that threshold. Allocated storage cannot be reduced, and storage autoscaling only grows; the way out AWS names is a blue/green deployment with smaller storage, or a new instance and a migration.
Aurora I/O-Optimized charges nothing for I/O requests but higher instance and storage rates; AWS recommends it once I/O makes up 25% of Aurora spend. Switching back to Standard is possible at any time, to I/O-Optimized once every 30 days. In newer Aurora versions, allocated space shrinks when tables or databases are dropped. Aurora Serverless can pause at a minimum capacity of 0 ACUs; no instance charge applies while paused, storage keeps billing. The idle time before a pause ranges from 300 seconds to one day; resuming typically takes about 15 seconds, and after a pause of over 24 hours it can take 30 seconds or more. A stopped RDS instance bills no instance hours, still bills storage and backups, and restarts by itself after seven days. Backup retention ranges from 0 to 35 days. For test environments Aurora creates copy-on-write clones that take additional storage only as data changes; after 15 such clones, the next one is a full copy.
RDS Extended Support is charged from the day after a major version's end of standard support, per vCPU and hour, including standbys in Multi-AZ deployments and read replicas; Reserved Instance discounts do not apply to it. The charge stops with an upgrade or when the database is deleted. The EngineLifecycleSupport parameter disables enrolment at creation or later; for an instance already past the date, disabling it triggers the automatic upgrade.
Azure
Azure SQL Database serverless bills compute by the second, at least the configured minimum vCores, and only storage while paused. Pausing starts after at least 15 minutes of inactivity on General Purpose (default 60 minutes) and at least 60 minutes on Hyperscale, where auto-pause is in preview. Microsoft recommends serverless for single databases with intermittent use, elastic pools for several. Azure Database for PostgreSQL offers the Burstable tier for development and low-concurrency workloads; stopping a server ends compute billing immediately, and after seven days it starts again. Point-in-time retention on Azure SQL Database ranges from 1 to 35 days (default 7), and long-term retention reaches ten years. Azure Advisor's database suggestions include reservations and lowering throughput on idle Cosmos DB containers.
Google Cloud
The Cloud SQL overprovisioned instance recommender looks at CPU and memory over the last 30 days for primary instances older than 30 days, not read replicas or high-availability instances, and reports only from an estimated monthly saving of USD 10. A second recommender flags idle instances. The activation policy NEVER stops an instance and its instance charges, while storage and IP addresses keep billing; read replicas do not support it. Automatic storage increases are permanent; storage shrinks only through an operation of its own that requires downtime and is not available on shared-core instances. If a final backup is taken when an instance is deleted, Cloud SQL keeps it for 30 days by default and bills it like other backups.
What it means for your cost
The order follows risk. First remove what nobody uses: idle instances, unused replicas, old manual snapshots. Then instance class and storage, then the billing model (serverless, pause, I/O configuration), and only then a commitment on the remaining base. A commitment bought before rightsizing is sized on the old capacity. Extended Support buys time for the upgrade at a surcharge on top of every other line; the end of standard support belongs in the upgrade plan like a contract end date. Non-production databases are the first candidates for pausing, stopping and clones (non-production cloud costs). Each lever shows in its own line of the billing data, and a saving is proven only when that line falls (from estimated to realised savings).
Where it goes wrong
- Storage grows and stays. Symptom: the storage line rises after a load peak and never falls. Cause: automatic increases are permanent, and RDS storage cannot be reduced.
- A stopped database runs again. Symptom: a stopped test database bills instance hours again after a week. Cause: RDS and Azure Database for PostgreSQL start automatically after seven days.
- A pause that never happens. Symptom: an Aurora Serverless instance never pauses, or wakes again and again. Cause: a minimum above 0 ACUs, an open client connection, or logical or binlog replication; and any connection attempt wakes it, even with invalid credentials.
- Extended Support twice over. Symptom: the Extended Support line is twice what was expected. Cause: on Multi-AZ both primary and standby are charged, and read replicas too.
- Back to Standard, then stuck. Symptom: after a test, an Aurora cluster cannot be set to I/O-Optimized again. Cause: switching to I/O-Optimized is possible only once every 30 days.
- A deleted instance keeps costing. Symptom: a backup line remains after a Cloud SQL instance is deleted. Cause: a final backup was taken at deletion, and it is kept and billed for 30 days by default.
Example
On 2026-10-16 the Amazon RDS for PostgreSQL pricing page gave, for version 12, whose standard support ended on 28 February 2025, in US East (Ohio), USD 0.100 per vCPU-hour for the first two years of Extended Support and USD 0.200 from 1 March 2027. The same page puts a db.r5.large at 2 vCPUs. As a Multi-AZ deployment with one standby that is 2 instances × 2 vCPUs × USD 0.100 = USD 0.40 per hour, USD 288 over 720 hours, and double that from March 2027. These amounts come on top of instance, storage and backups.
Sources
Read on 2026-10-16. AWS Aurora and RDS recommendations in Compute Optimizer, RDS storage types, RDS storage autoscaling, Aurora storage configurations, Aurora Serverless automatic pause, stopping an RDS instance temporarily, backup retention, Aurora clones, RDS Extended Support, Extended Support charges, Amazon RDS pricing, Amazon RDS for PostgreSQL pricing and Amazon Aurora pricing; Microsoft serverless compute tier for Azure SQL Database, automated backups in Azure SQL Database, Azure Database for PostgreSQL overview, stop a server and Azure Advisor cost recommendations; Google Cloud Cloud SQL overprovisioned instance recommender, idle instance recommender, start and stop instances, instance settings, storage shrink and backups.