The Managed Database Cost Illusion

Executive Summary

Here's something that happened at a company you probably know. They ran PostgreSQL on RDS. Multi-AZ, one read replica, 500 GB, 7 days of backups — the canonical production setup. Monthly bill: $1,667. Their architect assumed Aurora would be about the same — "both AWS, both PostgreSQL" — so they never ran the comparison. When they did, the number was $972. Same PostgreSQL. Same workload. Same region. $695/month difference on a single instance. Annualized: $8,340. That's not a pricing mistake. That's the cost of picking one AWS managed database service over another without understanding the five structural line items that make them different products with different bills.

Four cloud providers will all sell you a managed PostgreSQL instance. To a first approximation, the compute hardware is the same. The network latency between AZs is the same. The SLAs are within a few nines of each other. So the bill should be within a few percentage points of the same, right?

It's not. The same 8 vCPU, 32 GB PostgreSQL instance with Multi-AZ HA, 500 GB storage, one read replica, and 7 days of backup retention costs $920/month on Aurora and $1,440/month on RDS — a 1.6× gap. Change the storage class to io1 with provisioned IOPS, and the RDS number jumps to $1,970/month. That's 2.1× the Aurora bill for the same 8 vCPU PostgreSQL box. The differences aren't rounding errors. They're structural. And they compound.

The cause is not that one provider is "cheaper." It's that managed database pricing is not one product with four price tags. It's four structurally different billing models that each tax a different aspect of your workload. RDS taxes standby instances (full compute on Multi-AZ). RDS taxes provisioned IOPS (at a rate that can make the IOPS line item 19× larger than the storage it provisions). And RDS taxes backup retention — a tax that Aurora, Cloud SQL, and Azure DB do not levy at all. Meanwhile, Aurora taxes I/O requests instead of provisioned IOPS — cheaper for most OLTP workloads, potentially pricier for write-heavy ones.

This briefing walks through the five pricing traps, quantifies each with 2026 list prices, and models four real workload profiles side by side. The five traps are, collectively, the reason your managed database bill looks nothing like the compute-only napkin math you did when you picked a provider.

Trap #1: The Multi-AZ Standby Tax — One Checkbox Doubles Your Compute

On AWS RDS, Multi-AZ is presented as a checkbox. Availability & Durability → Multi-AZ deployment → Create standby instance. The UI makes it feel like a configuration toggle. It is a billing toggle. Checking that box provisions a synchronous standby instance in a second availability zone and charges you the full hourly compute rate for it. A db.r6g.xlarge (4 vCPU, 32 GB) at $0.342/hr in us-east-1 becomes $0.684/hr the moment you click. Compute cost doubles. No warning. No "this will increase your bill by" tooltip.

Google Cloud SQL calls it "regional high availability" and does the same thing. Azure calls it "zone-redundant high availability" and — you guessed it — the same. All three double your compute when you turn on HA. For a single 8 vCPU instance across a month (730 hours), the Multi-AZ premium alone is roughly $500/month on RDS, $543/month on Cloud SQL, and $482/month on Azure DB.

Amazon Aurora is the exception. Aurora's storage layer is a distributed, shared-nothing volume spread across three AZs by default. The standby instance reads from the same storage volume — there is no second copy to provision. Multi-AZ adds zero compute cost on Aurora. No standby tax. The same 8 vCPU Aurora instance in Multi-AZ is $922/month in compute — just the primary instance rate. Next to RDS at $1,025/month for the identical configuration, you're saving $103/month before you've touched storage, IOPS, or backups. The gap widens from there.

Trap #2: io1 IOPS — The 19× Multiplier Hiding Inside Your Storage Bill

General Purpose SSD (gp3 on RDS, PD-SSD on Cloud SQL, Premium SSD on Azure) is cheap. At ~$0.12–0.17 per GB-month, storage barely registers. A 500 GB gp3 volume is $69/month on RDS, $85/month on Cloud SQL, and $58/month on Azure. That's noise. Nobody picks a managed database provider because one charges $11/month less for 100 GB of storage.

Provisioned IOPS flips this. On RDS io1, storage itself is $0.20/GB-month — already a premium over gp3's $0.138. But the real cost is the IOPS line. io1 charges $0.065 per provisioned IOPS per month. The IOPS are provisioned, not consumed — you pay for them whether or not your database uses them. A 200 GB volume provisioned at 12,000 IOPS:

• Storage: 200 GB × $0.20 = $40/month
• IOPS: 12,000 × $0.065 = $780/month
• Total io1 cost: $820/month — of which storage is 4.9%, IOPS is 95.1%

The IOPS line item is 19.5× the storage cost it provisions. And if you've configured Multi-AZ with io1 on the standby as well, double everything. $1,640/month just to store and access 200 GB of data — which, on gp3, costs $28/month.

Teams hit this trap routinely. A typical pattern: a PostgreSQL instance described as "write-heavy" gets provisioned with 500 GB io1 at 12,000 IOPS. CloudWatch metrics later show sustained IOPS averaging 2,300 — easily serviced by gp3's baseline 3,000 free IOPS. The team was paying $780/month for IOPS capacity it used 19% of. Switching to gp3 dropped the bill from $1,540/month to $393/month. The IOPS line item was invisible until the quarterly cloud cost review — the invoice says "RDS," and nobody clicks through to the sub-items.

Cloud SQL and Azure DB don't have a direct io1 equivalent — both use throughput-provisioned storage models where IOPS scale with volume size, closer to gp3's model. If you're on RDS io1, you're paying a tax with no equivalent on the other three platforms. The question is whether your workload actually needs it. Measure first. Provision second.

Trap #3: The RDS Backup Retention Tax — A Charge Nobody Else Levies

Here's an asymmetry that belongs in fine print but somehow never makes it into the architecture decision doc: RDS is the only one of the four that bills for retained automated backups.

The AWS free tier for RDS backup storage is 100% of your database size — exactly one full copy. If your database is 500 GB, you get 500 GB of backup storage free. Beyond that, backup storage is billed at $0.095/GB-month. How do you exceed the free tier? Retention. At 1 day of retention, you have one snapshot — exactly one copy, within the free tier. At 7 days of retention with 10% daily data change, you're storing roughly 0.6 additional copies (6 days' worth: (7−1) × 10%). At 500 GB: 500 × 0.6 × $0.095 = $28.50/month. Manageable.

But retention compounds with database size. A 2 TB database at RDS's maximum 35-day retention, with 10% daily change, stores approximately 3.4 additional copies: 2,000 GB × 3.4 × $0.095 = $646/month. That's a line item that doesn't exist on Aurora, Cloud SQL, or Azure DB. Each of those platforms includes automated backups up to 100% of provisioned storage for free. Cloud SQL's free backup tier covers 7 days. Azure's covers 7–35 days depending on tier. Aurora includes continuous backup to 35 days at no additional storage charge — only the per-I/O cost for the write traffic that generates the backup data, which you're already paying as part of Aurora's I/O pricing.

If your RDS bill shows backup costs as the third-largest component after compute and IOPS, that's the tell. You're paying a tax that's zero on the other three platforms. The fix isn't necessarily to switch to Aurora — sometimes the compliance requirement for 35-day backups is non-negotiable. But you should know that the choice to stay on RDS is costing you an extra $500–700/month in a line item that's invisible on every other provider's invoice.

Trap #4: Read Replicas — Whose Storage Model Wins

Read replicas expose one of the deepest architectural differences between managed database platforms: the storage model. An RDS read replica is a full independent instance with its own storage volume. You pay for the replica's compute. You pay for the replica's storage. If the primary has 1 TB of data, the replica has another 1 TB. That's 2 TB total across the two instances.

Google Cloud SQL and Azure DB do the same. Each replica carries its own storage at the full GB-month rate. Three replicas on a 1 TB Cloud SQL database: 1 TB (primary) + 3 × 1 TB (replicas) = 4 TB of storage billed at $0.17/GB-month = $680/month in storage alone, before compute.

Aurora doesn't work this way. Aurora's storage is a single distributed volume shared by the primary and all replicas. Every replica reads from the same 1 TB volume. You pay for 1 TB of storage regardless of replica count. At $0.10/GB-month (Aurora storage is cheaper than RDS gp3, even before the shared-storage advantage), three replicas on a 1 TB Aurora cluster: $100/month in storage. Period. The replicas cost only their compute instances — no additional storage.

The gap widens with scale. At 3 replicas on a 2 TB database:

At three replicas, Aurora's shared volume is 4.6× cheaper than RDS gp3 on storage alone — before any of the other traps. For read-heavy SaaS architectures where replica count is the primary scaling mechanism, Aurora's storage model is not a nice-to-have. It's the cost structure that makes the architecture economically viable at scale.

Trap #5: The Commitment Discount Illusion — Compute vs Total Bill

Every cloud provider offers committed-use discounts. RDS Reserved Instances at 1-year No Upfront save ~35% on compute. 3-year saves ~60%. Cloud SQL committed use: 1-year ~45% off, 3-year ~64% off. Azure reserved instances: comparable. The discounts are real. The illusion is that they apply to your entire bill.

They don't. Reservations cover compute only. Storage, IOPS, backup retention, data transfer — every other line item stays at on-demand pricing. On a gp3-based RDS instance where compute is 70% of the bill, a 3-year reservation saving 61% on compute reduces total cost by ~43%. Good. On an io1-provisioned RDS instance where compute is 41% of the bill (IOPS is 45%, backup is 8%), the same 3-year reservation reduces total cost by ~25%. Still real savings, but half the headline number.

This isn't a reason to skip reservations. It's a reason to model the total bill, not the compute number, when evaluating commitment economics. A provider with lower on-demand compute but higher storage/IOPS costs may still be more expensive after commitment discounts — the discount only applies to the portion of the bill where they're cheaper. The Managed DB Cost Calculator applies commitment discounts to compute only, exactly as the providers bill, so the post-commitment comparison is apples-to-apples.

Four Workloads, Four Providers, One Bill Each

All scenarios: PostgreSQL, on-demand pricing (no commitment discount), us-east-1 baseline. Prices from vendor public rate cards, July 2026.

Scenario A: Dev / Sandbox — Single-AZ, No HA, No Replicas

2 vCPU · 8 GB · 50 GB gp3 · Single-AZ · 1-day backup · 0 replicas

At dev scale, the bill is small enough that the traps don't trigger. Single-AZ means no standby tax. 1-day backup means no retention tax. No replicas means no storage duplication. Compute dominates and the providers are within 15% of each other.

Takeaway: At this scale, pick based on ecosystem — which cloud you're already in, which tools your team knows. The $23/month spread between cheapest and most expensive is not a decision variable. But the architecture decisions you make here — engine, instance family, region — compound when you scale. Pick carefully even if the bill is small.

Scenario B: Production — Multi-AZ, One Replica, Moderate Storage

8 vCPU · 32 GB · 500 GB gp3 · Multi-AZ · 7-day backup · 1 read replica

This is the canonical production PostgreSQL setup. Multi-AZ triggers Trap #1 (standby tax). One replica triggers Trap #4 (storage duplication). The standby tax is the dominant gap — it's the single largest line-item difference between Aurora and the other three.

Takeaway: Aurora is ~42% cheaper than RDS — $693/month less. The RDS standby tax alone adds $499/month (the standby instance at full compute). The RDS replica pays $69/month for its own 500 GB storage; Aurora's replica pays $0. The $29/month RDS backup tax is visible but not dominant at this scale. At 8 vCPU production scale, the standby tax is the story. If this team is already in the AWS ecosystem and just assumed "RDS and Aurora are both AWS, the pricing must be similar" — the annual gap is $8,315. That's a mid-level engineer's monthly fully-loaded cost. On a cloud bill that looked "reasonable" at first glance.

Scenario C: Read-Heavy SaaS — Two Replicas, Large Storage

16 vCPU · 64 GB · 2 TB gp3 · Multi-AZ · 14-day backup · 2 read replicas

This is the read-heavy scale-out architecture. Two replicas means Trap #4 (storage duplication) compounds. The standby and two replicas on RDS each carry their own 2 TB — 6 TB of provisioned storage total, of which 4 TB is duplicate copies of the same data.

Takeaway: At this scale, Aurora is $2,267/month less than RDS — 43% cheaper. The RDS gap is now composed of three roughly equal components: the standby tax (~$998/month), the replica storage duplication (~$828/month for two 2 TB replicas), and the backup retention tax (~$133/month). The annual gap is $27,201. That funds a junior infrastructure engineer — or an extra failover region.

Scenario D: Write-Heavy io1 — The IOPS Bill Eats The Budget

16 vCPU · 64 GB · 500 GB io1 @ 16,000 IOPS · Multi-AZ · 30-day backup · 1 read replica

This is the trap fully sprung. io1 storage on a Multi-AZ deployment with a replica and 30-day retention. The io1 IOPS line item is the largest component of the RDS bill — larger than compute.

Compare to Aurora with the same workload profile. Aurora has no io1 line — it charges $0.20 per million I/O requests. For a workload generating 20 million I/O per month (moderate for a 16 vCPU instance): I/O cost is $4.00. Aurora total: compute $2,764.80 + storage $100 + I/O $4.00 + backup $0 = $2,868.80. That's $2,682.62/month less than RDS io1 — a 48% gap driven almost entirely by one line item.

Is Aurora's per-I/O model always cheaper than io1? No. A write-heavy workload generating 5 billion I/O operations per month at $0.20/million = $1,000/month in Aurora I/O charges — still $1,080/month less than the io1 IOPS bill. The crossover point where Aurora I/O exceeds io1 IOPS is roughly 10.4 billion I/O per month for a 16,000 provisioned IOPS setup. That's an enormous volume — you'd need sustained ~4,000 writes/second. Most OLTP workloads never approach it. And if yours does, you should be on DynamoDB, not PostgreSQL.

The Structural Story: Why The Gaps Exist

The five traps share a common thread: each is a point where one provider's architecture and one provider's billing model meet and produce a cost that compounds with scale. The Multi-AZ standby tax exists because RDS's architecture provisions discrete instances per AZ, while Aurora's distributed storage layer means the standby is a metadata entry, not a separate server. The io1 IOPS tax exists because AWS's io1 product was designed for an era when provisioned IOPS was the only way to guarantee disk performance — an era that ended when gp3 shipped with baseline IOPS included. The RDS backup retention tax exists because AWS chose to monetize a feature that competitors chose to bundle.

These are not bugs. They are pricing decisions that reflect each provider's architecture, market position, and — in some cases — legacy product lines that haven't been rationalized against newer offerings. The io1 pricing page still exists. RDS backup retention still bills. Teams still check the Multi-AZ box and discover the doubling on their next invoice. The traps endure because the information asymmetry between "what the pricing page says" and "what the bill says" is large enough that most teams don't notice until the quarterly cloud cost review — at which point they've already paid three months of the tax.

Decision Framework: Which Provider Wins Your Workload

The common thread: if you're on AWS and you care about cost at any scale beyond dev/sandbox, Aurora is almost always cheaper than RDS for PostgreSQL. Not marginally. Structurally. The standby tax alone is often $500+/month at 8 vCPU — enough to make the decision before you model storage, IOPS, or backups. The only reason to run RDS over Aurora for PostgreSQL is if you need a specific RDS-only feature (IAM database authentication with custom logic, certain parameter group settings, an extension Aurora doesn't support) or if you're locked into an RDS Reserved Instance you can't convert.

Concrete Steps: What To Audit This Quarter

1. Check if you're on RDS io1. Go to the RDS console → your instance → Configuration tab → Storage type. If it says "io1," pull your CloudWatch VolumeWriteIOPS and VolumeReadIOPS for the last 30 days. Compare to gp3 baseline (3,000 free + 500 per 100 GB above 400 GB). If your 95th percentile is below gp3 baseline + provisionable margin, you're paying for IOPS you don't use. Switch to gp3 and provision only what you need — the switch requires a blue/green deployment but the cost savings often pay for the migration effort in the first month.

2. Count your backup retention line item. Go to the AWS Cost Explorer → filter by Service = "RDS" → Usage Type = "RDS:BackupUsage." If the number is non-zero and you're on 7+ days of retention, model what that number would be on Aurora (hint: zero). The backup tax is the third-largest RDS cost driver nobody audits.

3. Model your exact workload. Use the Managed DB Cost Calculator. Plug in your actual instance size, storage class, topology, replica count, backup retention, and commitment term. The calculator runs all four providers side by side and shows you which line items diverge. All computation is client-side — your configuration never leaves your browser. Run once with your current provider, once with each alternative. The number you get is not an estimate. It's the actual list price, line by line.

4. Audit your commitment discount on total bill, not compute. Take your monthly RDS bill. Identify the compute portion (it's on the Cost Explorer, filtered by Usage Type = compute). Multiply by your reserved instance discount percentage. That's your real savings, not the headline number. If compute is less than 60% of your total bill, your effective discount is significantly lower than the published rate. This doesn't make reservations bad — it makes them accurately modeled. Use the calculator's commitment dropdown to see the real number.

5. If you have 2+ replicas, run the Aurora math. The storage gap alone often justifies the migration. Modeling a 16 vCPU, 2 TB, 2-replica setup: RDS gp3 storage is $1,104/month; Aurora storage is $200/month. That's $904/month in storage savings — before compute, IOPS, or backup differences. The migration effort is non-trivial (Aurora uses a different binary than RDS PostgreSQL, though wire-compatible), but the payback period is typically 1–2 months at this scale.

Frequently Asked Questions

Methodology & Disclosure

Pricing data is based on publicly available vendor rate cards accessed in July 2026. AWS RDS and Aurora pricing uses us-east-1 on-demand list rates for comparable instance families (RDS: db.r6g for Graviton, Aurora: db.r6g equivalent). Google Cloud SQL pricing uses us-central1 on-demand rates. Azure Database pricing uses East US on-demand rates. All costs are computed against a 730-hour month.

Backup retention cost modeling assumes 10% daily data change rate — a conservative estimate for OLTP workloads. Actual change rates vary by workload; transactional databases with high write volume may see 15–20% daily change, while read-heavy databases may see 3–5%. The formula is linear, so you can adjust proportionally. Aurora I/O cost estimates are based on typical OLTP I/O profiles; write-heavy analytical workloads may generate significantly more I/O operations and should be modeled with actual CloudWatch or Performance Insights data.

Disclosure: jslet is an independent research project. We are not sponsored by any cloud provider. This analysis was produced using our own Managed DB Cost Calculator and publicly available pricing data. We have no affiliate or financial relationship with any vendor discussed in this article.

References & Further Reading

1. AWS (2026). "Amazon RDS for PostgreSQL Pricing." aws.amazon.com
2. AWS (2026). "Amazon Aurora Pricing." aws.amazon.com
3. Google Cloud (2026). "Cloud SQL Pricing." cloud.google.com
4. Microsoft Azure (2026). "Azure Database for PostgreSQL Pricing." azure.microsoft.com
5. AWS (2026). "Amazon RDS Reserved Instances." aws.amazon.com
6. AWS (2026). "Monitoring DB Load with Performance Insights on Amazon RDS." docs.aws.amazon.com
7. Google Cloud (2026). "Cloud SQL Committed Use Discounts." cloud.google.com
8. AWS (2026). "Storage types for Amazon RDS." Detailed gp3/io1 comparison and baseline IOPS specifications. docs.aws.amazon.com

📜 Copyright & Attribution

📡 Enjoyed this? When four cloud providers sell the same database and one charges twice as much, the pricing model — not the technology — is the story. RSS covers one uncomfortable billing reality per week. No vendor sponsors. No tracking. RSS Feed → | More options →