AWS Database Savings Plans: The Good, The Bad, and The Ugly

In short

Database Savings Plans are a new AWS commitment instrument type that brings long-needed flexibility to the realm of managed databases.

While they broaden coverage to newer services and instance families, they also exclude some popular RDS and ElastiCache options. They also often deliver smaller discounts than classic Reserved Instances. In practice, most organizations will need a hybrid strategy mixing Database Savings Plans with RIs and on-demand, to maximize coverage and savings while mitigating risk.

Introduction

At Re:Invent 2025, AWS finally extended its flexible Savings Plans model to databases.

Since Savings Plans launched in 2019, customers have had an easier, more flexible alternative to classic Reserved Instances to reduce their cloud bill in exchange for long-term commitments.

Now, in late 2025, AWS has introduced Database Savings Plans, offering up to 35% discounts on managed database services.

This new commitment instrument covers a wide range of AWS database services, from Relational to NoSQL Databases and Caching engines. But they’re no silver bullet.

Below is Opsima’s take on the good, the bad and the ugly of the new Database Savings Plan.

I. The Good

Broader Coverage of Services

Database Savings Plans automatically apply to:

• Amazon Aurora
• Amazon RDS (any engine)
• Amazon DynamoDB
• Amazon ElastiCache
• Amazon DocumentDB
• Amazon Neptune
• Amazon Keyspaces
• Amazon Timestream
• AWS Database Migration Service (DMS)

This is a big deal. Previously, each of those services either had its own reservation option, or no coverage option at all. Now they can be covered by a single commitment instrument.

Fungibility across regions, engines and size

Like Compute Savings Plans, Database Savings Plans are not tied to a specific instance type, size, region, or engine.

You commit to $ / hour, and any eligible database usage up to that amount gets the discounted rate.

This means you can:

• Move from old engines to Aurora
• Shift from RDS (SQL) to DynamoDB (NoSQL)
• Migrate to newer instance families

All without caring about old RIs or needing to buy new commitments.

Covers both instance-based and serverless services

Database Savings Plans apply to both instance-based and serverless database offerings.

Serverless databases (higher discounts, ~30–35%):

• Aurora Serverless v2
• DocumentDB Serverless
• Neptune Serverless
• ElastiCache Serverless

Instance-based databases (~20% discounts):

• Aurora (Postgres / MySQL)
• RDS (Postgres, MySQL, MariaDB, SQL Server, Oracle, Db2)
• DocumentDB
• Neptune
• Timestream

Includes DynamoDB On-Demand Throughput

DynamoDB is now covered in both on-demand and provisioned modes (same for Amazon Keyspaces).

That means:

• On-demand (pay-per-request) throughput can now benefit from a committed spend.
• You get a baseline discount on workloads that historically had no reservation mechanism.

This finally brings predictable savings to spiky, serverless-style NoSQL workloads.

II. The Bad

Lower Discount Rates for Most Use Cases

The headline figure of “up to 35% savings” comes with fine print.

For most workloads, the discount is effectively much lower than that.

• Provisioned instances (Aurora, RDS, DocumentDB, Neptune) → 20%
• DynamoDB / Keyspaces on-demand → 18%
• DynamoDB / Keyspaces provisioned → 12%

By comparison, a typical 1-year No Upfront RDS RI often provides 30% to 35% off, so the new plan can feel underwhelming for classic instance-based databases.

Summary table

Gaps in coverage

RDS & Aurora

Database Savings Plans only apply to newer RDS & Aurora instance families (generations 7 and above), such as db.m7 and db.r7.

Older workhorses like m5, r5, r6g as well as burstable instance types t3 and t4g are all excluded.

Practically, you get savings only if you modernize to the latest families; older fleets must remain on RIs or on-demand.

ElastiCache

For ElastiCache, only Valkey (Redis-compatible OSS engine) is in scope.

Standard Redis and Memcached do not benefit from Database Savings Plans, so any savings there must be achieved through Reserved Nodes.

Commitment Model

Database Savings Plans are 1-year only and no-upfront only. This keeps things simple, but offers less discount depth than the classic 3-year, high-upfront RIs.

III. The Ugly

More Moving Parts in Cost Management

Database Savings Plans add another commitment type alongside Compute Savings Plans, EC2 Savings Plans, SageMaker Savings Plans, Reserved Instances, Reserved Nodes, Reserved Capacity and so on.

If, for instance, you operate both older RDS on gen6 and new Aurora clusters on gen7, you will end up having to purchase both RIs and Database SP in parallel. That means more work to:

• Plan migrations
• Decide coverage strategy
• Monitor utilization and avoid gaps or double-coverage

Not Yet a No-Brainer Like Compute Savings Plans

Compute Savings Plans and EC2 Savings Plan essentially made EC2 Reserved Instance mostly obsolete: the same or better discounts, much more flexibility.

Database Savings Plans are more nuanced:

• Discounts are often much lower than with Reserved Instances
• They offer only a 1-year term, so there is no maxing out savings with a 3-year option.
• Some legacy / niche workloads are still better off with existing RIs or just staying on-demand until the stack is modernized.

So DB SPs are another tool, not an obvious replacement for everything you’re doing today.

Opinionated Incentives

The structure clearly nudges you toward:

• Aurora and other modern managed engines
• Serverless variants
• Valkey instead of Redis
• Latest-gen instance families

This aligns with AWS’s product strategy and is acceptable if you’re already on or planning to move to these services, but it can feel punitive if you intentionally stick with Redis, older instances, or specific commercial engines.

Conclusion

Database Savings Plans are a meaningful step forward: one flexible, cross-service commitment for a broad set of AWS database offerings, including serverless and instance-based. They work best if:

• You are running recent generation instances or are planning to migrate.
• You have adopted Aurora, serverless and / or Valkey.
• You are comfortable with 1-year, no-upfront commitments and modest but flexible discounts.

They do not immediately replace RIs or existing DynamoDB reserved capacity for all use cases. For the next few years, most organizations will need to run a hybrid strategy: RIs for some workloads, Database SP for others, plus a migration roadmap towards what the Database Savings Plans cover best.