AWS Database Savings Plan

AWS Database Savings Plan: When It Makes Sense – and When It Doesn’t? – Part 1.

By Ran Blumenfeld, FinOps & CSM lead, TeraSky

For years, since the launch of the AWS Compute Savings Plan, cloud customers and the global FinOps community have been waiting for one thing: a comparable savings model for Amazon RDS. This expectation cut across industries, regions, and company sizes. It became the ultimate FinOps wish.
Ahead of every AWS re:Invent, when practitioners were asked which announcement they were hoping for most, Database Savings Plans for RDS consistently ranked at the very top.

At re:Invent 2025, that long-standing request was finally answered. AWS introduced the Database Savings Plan.
In this post, we take a clear, practical look at what the Database Savings Plan really delivers: how it works, what it covers, where the savings are compelling and where they are not. We focus primarily on Amazon RDS, one of the most significant cost drivers in modern AWS environments, and conclude with actionable guidance to help you decide whether (and how) to commit.

A Quick Refresher: What Is an AWS Savings Plan?

An AWS Savings Plan is a flexible financial commitment that provides discounted pricing in exchange for consistent hourly spend. Customers commit to a fixed dollar amount per hour for a defined term, traditionally one or three years. The commitment is evaluated strictly on an hourly basis and cannot be shifted across hours, days, or months.

In return, AWS applies discounted rates automatically to eligible usage. Commitments can start as low as $0.10 per hour and scale to any level required. Multiple Savings Plans can be purchased and layered over time.

First introduced in November 2019 for Amazon EC2, AWS Fargate, and AWS Lambda, Savings Plans quickly became a cornerstone of AWS cost optimization. Their success lies in their simplicity: discounts apply across regions, operating systems, for instance families, and sizes. Every hour, AWS automatically allocates the committed spend to the usage with the highest discount first, maximizing value while preserving operational flexibility.

Compared to Reserved Instances, Savings Plans typically offer slightly lower discounts, but with far greater freedom.

Introducing the Database Savings Plan

After nearly six years of anticipation, AWS launched the Database Savings Plan in December 2025. The scope of the program is broad, so this analysis is split into two parts. In this post, we focus on Amazon RDS, which consistently ranks among the top four cost components for most AWS customers. A follow-up post will address the remaining database services included in the plan.

Compute Savings Plan vs. Database Savings Plan

The natural point of comparison is the well-established Compute Savings Plan. From a coverage perspective, the Database Savings Plan is significantly broader. It spans 14 AWS services, or 22 distinct offerings when accounting for the full range of Amazon RDS engines.

While the Compute Savings Plan covers three core services, the Database Savings Plan enables customers to apply a single financial commitment across a wide and diverse database portfolio. For data-intensive organizations, this dramatically simplifies cost optimization.

There are, however, important trade-offs. At launch, AWS offers only a one-year commitment term for Database Savings Plans, compared to one- or three-year options for Compute Savings Plans. Shorter commitments inherently translate into lower discount rates. Given the relatively stable nature of database workloads, many customers had hoped for longer terms and deeper savings.

Another key difference is the payment model. Database Savings Plans are available exclusively with no upfront commitments. Historically, Partial and Full Upfront options unlocked higher discounts across other AWS commitment models. AWS has opted for the most commonly adopted structure, while retaining flexibility in a shifting interest-rate environment.

What’s Included: RDS and Aurora Coverage

Supported Database Engines

The Database Savings Plan covers eight database engines, grouped into three categories:

• License-free engines, such as MySQL and PostgreSQL
• Licensed engines, such as Microsoft SQL Server, where pricing includes the license
• Oracle and Db2, where the Savings Plan covers compute costs only, and customers must bring their own license (BYOL)

A Simple, Flat Discount Model

AWS intentionally kept the pricing model straightforward. Across regions, engines, and eligible instance types, the Database Savings Plan provides a flat 20% discount off On-Demand pricing for most RDS/Aurora modern instance-based engines. This applies equally to licensed and non-licensed databases.

Twenty percent. Predictable, consistent, and easy to model.

Instance Generation Requirements

Here is where simplicity meets constraint. Database Savings Plans apply only to generation 7 and newer RDS instances. Older generations, including generation 6 and even R6g Graviton-based instances, are not eligible.
Eligibility also varies by region and engine. Some combinations support m7i, m7g, or m8g, while others are limited to r7i, r7g, and r8g families. t4g is NOT included.
Bottom line: while the program is conceptually simple, validating instance eligibility is critical before committing.

Should You Upgrade Just to Qualify?

Once the generation restriction becomes clear, many FinOps and DevOps teams ask the same question: Should we upgrade from generation 6 to generation 7 purely to unlock the Savings Plan?
In theory, newer instance generations offer improved price-performance. In practice, financial math is more nuanced.
For example, a db.r6g.large MySQL instance in us-east-1 is approximately 11% cheaper than its generation 7 or 8 equivalent. While the 20% Database Savings Plan discount applies, the higher base price significantly offsets the benefit. The net savings typically land in the 9–10% range.
Unless an upgrade also enables meaningful rightsizing, upgrading solely to qualify for Database Savings Plans rarely produces compelling financial upside particularly when Reserved Instances remain available.

Database Savings Plan vs. Reserved Instances

Before Savings Plans existed, Reserved Instances (RIs) were the backbone of AWS cost optimization. RDS customers, in particular, relied heavily on RIs until late 2025.
The introduction of Size Flexibility for license-free SQL engines significantly increased RI adoption. As a result, many organizations achieved 60–70% RDS coverage using Reserved Instances, especially those operating under Enterprise Discount Programs (EDP).
For generation 6 M and R instances, RI discounts typically ranged from 33% to 42%. Partial Upfront payments added another 2–3%, with Full Upfront providing marginally more.
Compared to these figures, a flat 20% Savings Plan discount represents a meaningful reduction. While the absolute delta may appear modest, relative savings with RIs can be 60–75% higher.
For generation 7 Graviton-based instances (r7g), RI discounts dropped by 8–10%, making Database Savings Plans more competitive. This reduction does not apply to Intel-based instances. With Generation 8g, RI discounts increase again, widening the gap.
Practical Guidance for Size-Flexible RDS

• Generation 6 (M & R): Savings Plan not available → Reserved Instances
• Generation 7g (M & R): Database Savings Plan is often viable
• Generation 7i (M & R): Reserved Instances typically deliver higher savings
• Generation 8g (M & R): Reserved Instances typically deliver higher savings

Non-Size-Flexible Engines: A Clear Recommendation

For Microsoft SQL Server and Oracle, with a license included, Size Flexibility was never available. RI commitments required locking in exact instance sizes, which increased financial risk and limited adoption.
Database Savings Plans eliminate this rigidity entirely. For these engines, the Database Savings Plan is the recommended optimization model.

Aurora Serverless: The Biggest Winner

Aurora Serverless is arguably the service that benefits most from the Database Savings Plan.
Reserved Instances were never an option. With the Database Savings Plan, customers can immediately unlock 35% savings across all regions U.S., Europe, Asia Pacific, and Africa.
For Aurora Serverless users, the recommendation is simple: adopt Database Savings Plans as soon as possible.

Should You Commit to a Database Savings Plan?

With more than nine years of hands-on FinOps experience across startups, large enterprises, and public companies, one guiding principle remains constant: treat customer spending as if it were your own.
If you can confidently predict steady hourly database usage over the next year, committing to save 20–35% with minimal risk is an easy decision.
If you previously avoided Reserved Instances due to rigidity or uncertainty, Database Savings Plans provide a safer, more flexible entry point. Keep three principles in mind:

1. The commitment is one-year and irreversible.
2. You do not need full coverage; start with 40–60% and expand gradually.
3. Commitments are post-discount. For example, $10/hour of Aurora Serverless usage requires only a $6.5/hour commitment at a 35% discount.

For experienced teams, a blended strategy often works best: use Reserved Instances for stable, predictable workloads, and Database Savings Plans where flexibility is most important.
If you are still unsure, internal consultation or expert guidance can quickly clarify the optimal path. Feel free to approach TeraSky, and we will be happy to provide our Consulting service. The right commitment strategy translates directly into long-term, sustainable cloud savings.

Final Notes and Further Reading
This post reflects my professional perspective, based on hands-on FinOps experience and real-world customer environments. As with any AWS commitment model, the Database Savings Plan requires careful validation of eligibility by instance family, engine type, and AWS Region.
For the most accurate and up-to-date information on which instance types and regions are eligible for the Database Savings Plan, I strongly recommend reviewing the official AWS documentation:
https://aws.amazon.com/savingsplans/database-pricing/

Ultimately, successful cloud cost optimization is not about choosing a single model it’s about applying the right commitment to the right workload, at the right time.