Managed Database Pricing: The Instance Rate Decides the Least
Four providers meter four different things, and each one hides the pain somewhere else: a per-request I/O charge, a storage tier you cannot shrink, an HA checkbox that doubles the bill, a size you configured once and now pay for forever.
The instance rate is the number everyone compares, and it is the number that decides the least. It is also the only one the four big managed database services made comparable, which is why so many bills end up somewhere nobody modeled.
Managed relational databases are priced on four axes that do not line up between providers: compute, storage, I/O, and high availability. Each vendor hides the pain in a different one. Aurora Standard meters I/O per request. Cloud SQL doubles everything when you tick the HA box. Azure SQL bills you for the size you configured rather than the size you use. RDS is the most conventional of the four and still has a performance cliff people cross without noticing.
Rates and rules below came off AWS, Google, and Microsoft documentation on 22 August 2026. Pull your own numbers for your region before you commit to anything, and note that only one of these four publishes figures a script can read.
Aurora Standard bills per I/O, and it compounds quietly
This is the one that ambushes people, because it is metered rather than provisioned. Aurora Standard charges $0.20 per million I/O requests on top of compute and storage, where storage runs $0.10 per GB-month. A database sustaining a few thousand I/O per second generates hundreds of millions of requests in a month, and nothing warns you. The line just gets bigger.
Aurora I/O-Optimized removes the per-request charge entirely and charges more for the base instead: storage at $0.225 per GB-month, which is 2.25 times Standard, and instances about 30% higher. AWS’s own pricing example puts a db.r6i.large at $0.29 an hour on Standard against $0.377 on I/O-Optimized.
Rather than guessing at a crossover, use the rule AWS publishes in its own documentation. Aurora I/O-Optimized is the better choice when your I/O spending is 25% or more of total Aurora spending, and below that Standard wins. AWS also claims up to 40% savings once you are past that line. Older comparisons circulate a figure of roughly 500,000 I/O per instance-hour as the break-even; I could not find that in AWS’s documentation, and the 25% rule is both easier to check and actually written down.
The switch is not symmetric, which the storage documentation spells out. You can move from I/O-Optimized to Standard at any time. You can move from Standard to I/O-Optimized once every 30 days. So the expensive direction is the one you can reverse freely, and the cheap direction is the one you get one shot at per month. On non-NVMe instance classes the switch is online; on NVMe-based classes it needs an engine restart, which means a brief outage.
The decision is per cluster, not per account. A write-heavy transactional primary and a read-heavy analytics cluster can reasonably land on different configurations.
The RDS cliff nobody mentions is a good one
RDS gp3 gives you a baseline of 3,000 IOPS and 125 MiB/s, which covers most workloads. What the pricing page does not lead with is that at 400 GiB the baseline jumps to 12,000 IOPS and 500 MiB/s, for free, because RDS starts striping across four volumes instead of one. For PostgreSQL, MySQL, MariaDB, and Db2 the threshold is 400 GiB; for Oracle it is 200 GiB; RDS for SQL Server does not stripe at all and stays at the lower baseline whatever the size.
That has a practical consequence for anyone sitting at 350 GiB and buying provisioned IOPS to get past a throughput ceiling. Growing the volume may be cheaper than provisioning performance, and you are going to grow into it anyway.
The other thing worth knowing about RDS storage is that it goes one way. Allocated storage grows, autoscaling grows it for you, and nothing shrinks it back. One batch job that balloons a table leaves you paying for that high-water mark until someone rebuilds the instance. Check allocated against used once a quarter.
Aurora no longer works that way, which is a change worth knowing if your mental model is a few years old. Current versions reduce allocated space when you drop tables or databases, so the cluster volume tracks what you use rather than the worst thing that ever happened to it.
High availability is not a checkbox, it is a multiplier
Every provider presents HA as a toggle. Every provider charges for it differently, and two of the three tell you exactly how much in their docs.
| What HA costs | Where it is documented | |
|---|---|---|
| Cloud SQL | “An HA-configured instance costs twice as much as a standalone instance. This price includes CPU, RAM, and storage.” | HA overview |
| RDS Multi-AZ | A standby instance, so compute roughly doubles. Storage is mirrored rather than separately surcharged | RDS pricing |
| Azure SQL | Folded into the tier. Business Critical adds three HA secondary replicas, “approximately 2.7 times higher than it is in the General Purpose service tier” | vCore tiers |
Cloud SQL is the bluntest: the doubling covers storage too, not just compute, so a storage-heavy instance pays the multiplier on its largest line. RDS Multi-AZ doubles the compute and leaves storage alone, and if you are paying for a standby anyway, Multi-AZ with two readable standbys turns that idle capacity into read throughput for more money rather than none.
Azure is the odd one out in a way that is easy to misread. There is no HA switch to find, because the redundancy is the tier. General Purpose gives you one replica and no read scale-out. Business Critical gives you three replicas and one readable secondary at roughly 2.7 times the price. Hyperscale lets you choose zero to four HA replicas and bills per replica, which is the only one of the four that lets you buy a fraction of high availability.
Azure bills you for the size you configured, not the size you use
This trap is specific to Azure and it is worth its own paragraph, because it does not exist anywhere else on this list.
On General Purpose and Business Critical you are charged for the maximum storage size configured for the database, not for what the data occupies. Configure 500 GB, store 40 GB, pay for 500 GB. On top of that, when you set a maximum data size, Azure adds 30% billable storage automatically for the log file. Hyperscale is the exception and bills only allocated data storage with a 10 GB minimum, and does not charge for log storage at all.
That difference is now the default path, because Microsoft’s documentation calls Hyperscale “the recommended and default service tier for all new and modernizing OLTP and HTAP workloads.” If your mental model of Azure SQL is General Purpose versus Business Critical, it is a generation out of date.
One more Azure detail that changes the arithmetic before you start: reserved instance pricing exists only in the vCore purchasing model. The DTU model bundles compute, storage, and I/O into one opaque unit and cannot take a reservation. If someone is comparing a DTU price against a vCore price, they are comparing a list rate against a rate you would never actually pay.
Worth noting for anyone benchmarking Azure against AWS: Azure SQL does not charge for IOPS on any of the three vCore tiers. The I/O cost is inside the tier, which is the opposite of Aurora Standard’s model and a large part of why per-instance comparisons between the two go wrong.
Reservations, and the term you can actually honor
Committed capacity is the biggest lever once the workload is steady, and the shapes differ. AWS sells RDS and Aurora Reserved Instances, Google sells committed use discounts, Microsoft sells Azure Reservations and stacks Azure Hybrid Benefit on top for anyone bringing their own SQL Server licenses.
The one number to read carefully is Microsoft’s headline discount, because reaching it requires stacking a three-year reservation with Hybrid Benefit. If you do not already own SQL Server licenses, that figure was never yours. Reservation alone puts you in the same band as everyone else.
The practical rule is duller than the discount table: commit one-year terms against the baseline you are confident you will still be running, and leave the rest on demand. A three-year commitment does not survive a migration, and this category re-architects more often than a three-year plan assumes. The commitment discount post covers how those instruments behave on the compute side, including which ones the data tier cannot use.
Deciding without a spreadsheet war
Pick the axis your workload actually stresses and let it choose for you.
If it is write-heavy on Aurora, the I/O line is your problem. Pull VolumeReadIOPs and VolumeWriteIOPs from CloudWatch, work out what I/O is as a share of your total Aurora bill, and if it is over a quarter, switch. Remember you get one switch per 30 days in that direction.
If it is storage-heavy, the per-GB rate matters more than the instance and it compounds every month you keep the data. On Azure that argues for Hyperscale, where you pay for what you allocated rather than what you declared.
If it needs HA, budget for the compute roughly doubling everywhere, plus storage on Cloud SQL, plus the jump to Business Critical on Azure if you assumed General Purpose already gave you replicas.
And if it is already in production, the useful move is not a comparison at all. Split the actual bill into compute, storage, I/O, and HA and see which line is winning. It is usually not the one on the slide that justified the platform.