I Compared Every AWS Database Savings Plan Rate to Reserved Instances. The Results Weren't Even Close.

AWS launched Database Savings Plans in December 2025, promising "up to 35% savings" with the flexibility to move across RDS engines, ElastiCache, OpenSearch, and more. Sounds great on paper. But how do they actually stack up against the tried-and-true Reserved Instances?

I wrote a script that queries the AWS Price List API directly -- no blog hearsay, no pricing calculator screenshots -- and compared No-Upfront 1-year Database Savings Plans against No-Upfront 1-year Reserved Instances across RDS, OpenSearch, and ElastiCache in us-east-1.

349 head-to-head comparisons. RI won every single one.

The Headline Numbers

Zero wins for Savings Plans. Not one instance type, across any service, any engine, any family.

The Pattern: Graviton Wins for RI, Intel Gets Punished

Digging into the RDS numbers reveals a fascinating split by instance family:

The 7th-gen Graviton instances have the smallest SP premium (~4%). But here's the twist: for r8g and m8g (Graviton4), RIs got significantly cheaper to reflect the newer silicon's lower cost, while Savings Plan rates stayed at r7g-level pricing.

Example: Aurora MySQL r8g.large RI costs $0.1850/hr. The SP rate? $0.2208/hr -- the exact same rate as r7g.large. AWS updated RI pricing for Graviton4 but forgot (or chose not to) update SP rates. You're paying last-gen prices for current-gen hardware.

The same ~19% gap applies to all Intel instances (r7i, m7i), suggesting SP rates were benchmarked to Graviton3 pricing and Intel RI discounts are simply deeper.

What It Looks Like in Dollars

For a single Aurora MySQL r8g.16xlarge:

That's $10K/year wasted per instance by choosing SP over RI. Scale that to a fleet of 20 database instances and you're looking at $200K/year in avoidable spend.

OpenSearch: Remarkably Consistent ~16% Premium

OpenSearch pricing is more uniform than RDS. The SP premium sits at +15.9% regardless of instance family -- c7g, r7g, r8g, m7g, m8g, oi2, or1, or2 -- they all cluster within +15.3% to +16.7%.

ElastiCache: SP is Valkey-Only

This one surprised me. Database Savings Plans for ElastiCache currently only cover Valkey -- no Redis, no Memcached. And only for three instance families: r7g, m7g, c7gn.

If you're running Redis (which is most ElastiCache deployments today), there is no Savings Plan option at all. You must use RIs.

Where they do overlap (Valkey r7g), the SP premium is ~17.6%:

The Coverage Gap Problem

Savings Plans only cover newer-gen instances. Here's the coverage matrix:

If you're running anything older than 7th-gen, Savings Plans simply don't apply.

DynamoDB: Where SP Finally Has a Story

DynamoDB flips the script. Its legacy Reserved Capacity always requires upfront payment -- there is no "No Upfront" option. This makes Database Savings Plans the only zero-upfront commitment discount for DynamoDB.

Provisioned Mode

At scale -- 1,000 WCUs provisioned for a year:

Reserved Capacity saves 4.5x more, but locks up $1,500 in upfront capital per 1,000 WCUs. For large DynamoDB deployments with tens of thousands of WCUs, that upfront bill gets substantial.

On-Demand (Pay-Per-Request) Mode

This is where SP has no competition at all. There are no reservations for pay-per-request DynamoDB:

If you're running DynamoDB in on-demand mode, SP is the only way to get a discount. Take it.

DynamoDB Infrequent Access

SP also covers DynamoDB IA table classes with a 12% discount -- another area where Reserved Capacity doesn't reach.

Aurora Serverless v2: The Other SP Win

There are no RIs for serverless workloads -- SP is the only commitment discount available.

If you're running Aurora Serverless v2, a Database Savings Plan is a no-brainer -- it's 35% off with no alternative.

So When Do Savings Plans Actually Make Sense?

1. Aurora Serverless v2. No RIs exist. SP is the only game in town. Take the 35%.
2. DynamoDB (especially on-demand mode). SP gives 18% off pay-per-request with zero upfront. Reserved Capacity saves more for provisioned mode but demands upfront capital. SP is the only option for on-demand mode and IA tables.
3. Your fleet is in constant flux. If you're actively migrating engines (MySQL to Aurora), switching between RDS and OpenSearch, or scaling across instance families every quarter, the ~4-19% premium might be worth the flexibility of not managing individual RI purchases.
4. You can't operationalize RI management. Managing RIs across dozens of accounts, instance types, and services is genuinely hard. One SP commitment is simpler if you lack the tooling or team to optimize RI coverage.
5. You value cross-service pooling. A single SP commitment covers RDS, Aurora, ElastiCache, OpenSearch, DynamoDB, DocumentDB, and Neptune. If your workloads shift between these services, that fungibility has real value.

But for instance-based services (RDS, OpenSearch, ElastiCache) with a stable fleet -- Reserved Instances save you 4-19% more, with zero flexibility tradeoff because you weren't going to change anyway.

Methodology

All prices queried live from AWS APIs on April 14, 2026 using:

• aws rds describe-reserved-db-instances-offerings (RDS RIs)
• aws elasticache describe-reserved-cache-nodes-offerings (ElastiCache RIs)
• aws opensearch describe-reserved-instance-offerings (OpenSearch RIs)
• aws savingsplans describe-savings-plans-offering-rates (Database SP rates)
• aws pricing get-products (Aurora Serverless v2 On-Demand, DynamoDB pricing)

Region: us-east-1. Payment option: No Upfront (SP and RIs). Term: 1 year. Single-AZ only (RDS). I/O Optimized Aurora variants excluded from instance comparisons. DynamoDB Reserved Capacity uses "Heavy Utilization" (the only option available), which includes an upfront fee amortized over 8,760 hours.

The "up to 35% savings" on Database Savings Plans is real – for Aurora Serverless v2 and DynamoDB on-demand mode. For instance-based services, it's measured against On-Demand. Reserved Instances also save against On-Demand. They just save more. The nuance matters when you're committing six figures.