At re:Invent 2025, AWS announced the launch of Database Savings Plans, a flexible pricing model to reduce database costs. From our perspective, this finally fills a long-standing gap in AWS’s discount strategy for non-Compute services. In this post, we’ll break down what Database Savings Plans are and enumerate the critical details you’ll want to understand before using them.
What Are Database Savings Plans?
Database Savings Plans work similarly to other AWS Savings Plans and are now the fourth Savings Plan type along with Compute, EC2 Instance, and SageMaker. You commit to a fixed, post-discount dollar-per-hour spend level which offsets applicable on-demand usage based on discount rates ranging from 12% to 35%. Database Savings Plans are most akin to Compute Savings Plans in that they float globally across multiple database services, instance families, engines, regions, etc.
In short, you are committing to global database usage in exchange for a discount. Just as Compute Savings Plans brought discount support for Fargate and Lambda in addition to EC2, Database Savings Plans broaden the number of database-related services that can be discounted beyond RDS, ElastiCache, DynamoDB, etc. And unlike Reserved Instances (RIs) which are tied to a specific service, region, instance family, and engine, Database Savings Plans give you the flexibility to upgrade or switch your databases over time while having the discount coverage follow (keeping in mind discount rates could change, which impacts coverage). In general, this is a very welcome addition to the AWS commit discount lineup!
Key Things to Know about Database Savings Plans
1. Database Savings Plans offer broad coverage but there are still gaps
Database Savings Plans support a breadth of database services, including services that weren’t discountable before; however, they don’t cover everything that is discountable with a Reserved Instance/Node. This means savings are possible that weren’t possible before, but also means certain data-related services can only be discounted with a Reserved Instance/Node.
This is a solid start for Database Savings Plans but we hope AWS evolves the set of supported services over time. Here’s a breakdown of what the coverage matrix looks like by service.
| Service | Discountable with Database Savings Plans | Discountable with Reserved Instance/Node or Provisioned Capacity |
|---|---|---|
| RDS and Aurora |  | |
| Aurora Serverless | |  |
| Aurora DSQL | | |
| DynamoDB * | | |
| ElastiCache ** | | |
| ElastiCache Serverless | | |
| DocumentDB | | |
| DocumentDB Serverless | | |
| Neptune | | |
| Neptune Serverless | | |
| Keyspaces | | |
| Timestream | | |
| DMS | | |
| DMS Serverless | | |
| OpenSearch | | |
| RedShift | | |
| MemoryDB | | |
* Database Savings Plans add a discount option for On-Demand DynamoDB usage, which previously only had discounting for Provisioned Capacity
** Only Valkey is discountable with Database Savings Plans (no Redis or Memcached coverage)
2. Database Savings Plans bias toward newer-generation instance types
A major benefit of Database Savings Plans is they let you modernize without stranding discounts. But there is a catch: for provisioned, instance-based databases, eligibility at launch is entirely skewed toward newer generation instance families.
In practice, this means that if a meaningful chunk of your usage within the eligible services is still on older families (e.g. m5, r5, r6g, etc.), Database Savings Plans won’t reduce the cost until you modernize. If that is you, you will likely want a commit discount portfolio mix of Reserved Instances/Nodes and Database Savings Plans.
It is important to distinguish between services using an instance-based provisioning model and those utilizing serverless abstractions. Because Database Savings Plans prioritize modern hardware flexibility, these generation-specific restrictions apply primarily to provisioned instances. For non-instance-based services, the Database Savings Plans coverage scales based on metered throughput or capacity units.
| Service | Eligibility Criteria | Implementation Constraints |
|---|---|---|
| RDS, Aurora, Neptune, DMS, DocumentDB | Gen 7 families and newer | Legacy instance families (Gen 6 and below) require standard Reserved Instances |
| ElastiCache | Only Valkey, Gen 7 families and newer | Redis and Memcached engines remain excluded from Database Savings Plans; utilize Reserved Nodes here |
| DynamoDB, Keyspaces | Provisioned/On-Demand throughput | Instance generations are abstracted; Database Savings Plans apply to RCU/WCU consumption |
| Serverless DB Options | Metered serverless usage | Applicable only via Database Savings Plans; no RI equivalent |
3. Database Savings Plan discounts are generally lower than comparable Reserved Instances
Just like Compute Savings Plans typically provide less discounts than comparable EC2 Standard RIs/EC2 Instance Savings Plans, Database Savings Plans also provide lower discounts than comparable Reserved Instances/Nodes. This is the trade for more flexibility. It’s often a good trade but not always, so it should be made thoughtfully.
The table below compares 1-year, No Upfront discount rates across a sampling of instance types in us-east-1. Note that Reserved Instances provide consistently higher discounts than Database Savings Plans, in some cases as much as 65% more discount. For the complete set of discount rates available with Database Savings Plans, please see the AWS Database Savings Plan pricing page here.
| Service | Engine | Instance Types | Database Savings Plans Discount | Reserved Instance/Node Discount |
|---|---|---|---|---|
| RDS | MySQL, PostgreSQL, MariaDB | m8g.*, r8g.*, m7i.*, r7i.* | 20% | 33% |
| RDS | MySQL, PostgreSQL, MariaDB | m7g.*, r7g.* | 20% | 23% |
| Aurora | MySQL, PostgreSQL | r8g.*, r7i.* | 20% | 33% |
| Aurora | MySQL, PostgreSQL | r7g.* | 20% | 23% |
| ElastiCache | Valkey | m7g.*, r7g.*, c7gn* | 20% | 32% |
This gap in discounts can significantly impact your savings and Effective Savings Rate, so it’s worth reinforcing this point with a quick example. Consider a 1-year No Upfront Database Savings Plan versus a 1-year No Upfront Reserved Instance for an Aurora MySQL db.r8g.16xlarge instance.
The on-demand cost is $8.84/hour or $77.4K/year. With a Database Savings Plan, you receive a 20% discount which equates to savings of $15.5K/year. With a Reserved Instance, the discount increases to 33% which equates to $25.6K/year or 65% more savings. Bottom line: In the same way that intelligently blending a mix of Compute Savings Plans (flexible, lower discounts) and EC2 Instance Savings Plans (rigid, higher discounts) will maximize savings and ESR in compute, the same is true of Database Savings Plans (flexible, lower discount) and Reserved Instances/Nodes (rigid, higher discounts).
4. Database Savings Plans cover the highest discounts first
Similar to how Compute Savings Plans work, a single Database Savings Plan commitment automatically applies to your highest discount-eligible usage first. In practice, that usually means coverage starts with Aurora Serverless, where discounts can reach up to 35%.
Any remaining committed spend then rolls down to other eligible usage across services like ElastiCache or DynamoDB. This behavior matches how modern architectures evolve (more managed, more serverless, more mix-and-match) and helps avoid the “stranded commitment” problem that RI-heavy strategies can create.
| Service | Instance Discount | Serverless Discount |
|---|---|---|
| Aurora, RDS | 20% | 35% |
| ElastiCache, Neptune, Amazon DocumentDB | 20% | 30% |
| DMS | 20% | 20% |
| Timestream | 20% | – |
| Aurora DSQL, On-demand DynamoDB, On-demand Keyspaces | – | 18% |
| Provisioned DynamoDB, Provisioned Keyspaces | – | 12% |
5. Database Savings Plans and Private Pricing Agreements (PPAs) have a complicated relationship
Database Savings Plans interact with cross-service PPAs and service-specific PPAs differently. The good news: Database Savings Plans play well with cross-service PPAs. The Database Savings Plan discount applies to list rates first, and then the cross-service PPA applies its discount to the remaining balance. Database Savings Plans provide incremental savings in this case and remain a great addition to the toolkit.
Where things get complicated is with service-specific PPAs. Database Savings Plans exclusively apply to list rates, as do service-specific PPAs. Both discounts cannot apply to the same usage, and Database Savings Plans will crowd out and nullify service-specific PPAs. Since the highest discounted usage is covered by Database Savings Plans first, an environment with a service-specific PPA in Aurora, for example, will block the utility of a Database Savings Plan for the remaining usage with lower discount rates.
To further illustrate this point, let’s look at an environment with $75K/year of on-demand Aurora instance usage and $36K/year of on-demand DynamoDB. This environment has a service-specific PPA for Aurora, which secures a 40% discount, or $30K/year in savings.
| Service | Annual List On-Demand | Active Discount | Discount | Annual Savings |
|---|---|---|---|---|
| Aurora | $75K | Service-Specific PPA | 40% | $30K |
| DynamoDB | $36K | N/A | – | – |
| Total | $111K | – | – | $30K |
These savings are great, but we’d like to earn additional savings on the uncovered on-demand DynamoDB as well. Database Savings Plans offer an 18% discount here, which is less than the 20% earned by Aurora instances. As a result, we would need to purchase enough of a Database Savings Plan to cover the full $75K/year in on-demand Aurora to reach the remaining $36K of on-demand DynamoDB. By covering the full $111K with a Database Savings Plan, your total savings drop to ~$22K. This is a 28% reduction compared to your original PPA-only savings. In this scenario, adding a ‘discount’ actually costs you money.
Because the Database Savings Plan (20%) ‘wins’ the coverage battle over the PPA (40%) for the Aurora instances, you effectively swap a higher discount for a lower one.
| Service | Annual List On-Demand | Active Discount | Discount | Annual Savings |
|---|---|---|---|---|
| Aurora | $75K | Database Savings Plan | 20% | $15K |
| DynamoDB | $36K | Database Savings Plan | 18% | $6.5K |
| Total | $111K | – | – | $21.5K |
Database Savings Plans are extremely risky if you have a service-specific PPA! It is also important to note that the Recommendations page does not account for service-specific PPAs when generating Database Savings Plan recommendations.
6. Database Savings Plans are only offered as a 1-year commitment term
This is a solid start but is still a miss. With less flexible tools like Reserved Instances, committing to a 3-year term is harder to justify except for the most stable database workloads.
Since Database Savings Plan commit applies to AWS database service usage globally, many customers would prefer a 3-year term with higher discounts. We expect 3-year terms will come with time as AWS adds more capabilities, but that isn’t an option for now.
7. They are only available with a No Upfront prepayment option
Database Savings Plans are No Upfront only. For those willing to prepay (Partial or All Upfront) to earn a higher discount, that option isn’t available today. Note that RDS Reserved Instances offer 1-year terms with No, Partial, and All Upfront options. Again, solid start for Database Savings Plans, but it’s another gap we expect AWS will eventually close.
8. Existing Database Savings Plans will automatically extend to new eligible database offerings and instance generations
One underrated upside of Database Savings Plans is that you’re not locking your discount to today’s exact footprint. As AWS adds new eligible database services, instance types, or regions, your existing Database Savings Plan can automatically start applying to that newly-eligible usage without you having to re-buy commitments just to keep up with modernization.
9. There’s a 7-day return window (with limits)
AWS also gives you a limited safety valve: Savings Plans can be returned within 7 days of purchase, as long as they are $100/hour or less, within the same calendar month, and you haven’t hit your return quota.
Due to this limit, we suggest making smaller purchases over time, for example, if you need $500/hr of commitment, begin with $99 and observe coverage in your billing data, and then add more over time. This approach maximizes your option value and reduces risk.
It’s not a get-out-of-jail-free card, but it is enough to make “start small, validate, then scale” a more practical way to adopt Database Savings Plans.
Final Thoughts
AWS’s new Database Savings Plans mark a significant evolution in how users can manage costs across non-Compute workloads. They’re adding much-needed flexibility for dynamic cloud environments.
At ProsperOps, we see this as a powerful new lever. Whether you’re running predictable workloads, fast-changing dev environments, or a mix of both, there’s now a more effective way to structure your AWS database discounts while maintaining flexibility. We’re actively working to support Database Savings Plans as part of Autonomous Discount Management for AWS. Stay tuned for more updates.
Get in touch to learn how ProsperOps can automatically optimize your database spend right now.
