.png)
AWS Database Savings Plans are a spend-based discount model for managed AWS database services including Amazon RDS, Aurora, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, and DMS. Instead of committing to a specific instance type or Region, DB teams commit to a consistent hourly spend for one year and AWS applies discounts automatically across all eligible usage. Usage.ai added native support for this commitment model in January 2026.
Amazon Web Services expanded its Savings Plans portfolio by introducing Database Savings Plans, a new flexible pricing model that can reduce managed database costs by up to 35%. This offering extends the Savings Plans model beyond compute and into AWS’s managed database ecosystem for the first time, giving DB teams a commitment option that adapts to how modern database environments actually operate.
Until now, services like Amazon RDS, Aurora, DynamoDB, ElastiCache, and other managed database engines relied almost entirely on Reserved Instances, which required teams to commit to specific instance types, engine versions, and Regions. Database Savings Plans change that equation entirely.
The reaction across the industry was immediate. At re:Invent, Database Savings Plans received some of the loudest applause of the keynote, reflecting how long customers had been waiting for a more adaptable commitment option for databases. AWS CEO Matt Garman unveiled the announcement with just two seconds remaining on the lightning round shot clock. Analysts and practitioners echoed that sentiment, noting that this release removes many of the long-standing economic and operational barriers associated with Reserved Instances.
The shift is significant for engineering and FinOps teams. This is the clearest signal yet that AWS is moving database commitments toward the same flexible model that transformed compute pricing in 2019.
What Are AWS Database Savings Plans?
AWS Database Savings Plans are a spend-based commitment model for managed AWS database services. Instead of locking into a specific instance class, database engine, or Region, DB teams commit to a consistent dollar amount of database spend per hour. AWS then applies discounts automatically across all eligible usage up to the committed amount, every hour, without any manual action required.
This mirrors the pricing approach used for Compute Savings Plans, which AWS introduced in 2019, and extends it directly to the database layer. The plan covers both provisioned and serverless database usage, offering a fundamentally more flexible alternative to the rigid, instance-specific structure of Reserved Instances.
How the Commitment Works
With the new model, DB teams commit to a specific hourly spend amount for a one year term. AWS evaluates eligible database usage continuously each hour and applies the discount wherever it provides the most value within the committed amount. Usage beyond the committed hourly spend is charged at standard on-demand rates.
The commitment covers different instance families within the same service, multiple AWS Regions depending on the plan type selected, and both provisioned and serverless deployment models for supported services. A single plan can cover an RDS db.m7g instance in one Region and an Aurora instance in another, without requiring separate Reserved Instances for each configuration.
Payment Options
Database Savings Plans offer only one payment structure: No Upfront. The full commitment is billed as monthly charges over a 1-year term with no upfront payment required. AWS provides a separate ‘Advance Pay’ billing feature that allows pre-payment of monthly charges for accounting purposes, but this is not a payment option on the Savings Plan itself. This is a key structural difference from Compute and EC2 Instance Savings Plans, which offer All Upfront, Partial Upfront, and No Upfront options.
Which AWS Services Are Covered by Database Savings Plans?
Database Savings Plans apply automatically across eligible usage for a broad set of AWS managed database services. This is one of the most significant differences from the previous commitment landscape, where only certain services had viable Reserved Instance options and many had no practical commitment path at all.
The full list of supported services includes:
- Amazon Aurora
- Amazon RDS
- Amazon DynamoDB
- Amazon ElastiCache, supported for the Valkey engine only. Standard Redis and Memcached continue to require Reserved Nodes.
- Amazon DocumentDB with MongoDB compatibility
- Amazon Neptune
- Amazon Keyspaces
- Amazon Timestream
- AWS Database Migration Service
As AWS expands Regions, introduces new instance types, or updates these managed database offerings, the Savings Plans model will apply to newly supported usage as those capabilities become available. AWS recommends verifying specific instance and engine eligibility in the AWS console or pricing pages before purchasing.
| AWS Service | What Is Covered | What Is Not Covered | Still Requires Reserved Instances? |
| Amazon Aurora | Gen 7+ provisioned instances (db.r7, db.r8g, db.m7 families); Aurora Serverless v2; Aurora DSQL | Older families (db.r5, db.r6g, db.m5 and earlier) | Yes, for older-generation instances |
| Amazon RDS | Gen 7+ provisioned instances (db.r7, db.r8g, db.m7 families) | db.r5, db.r6g, db.m5, db.t3, db.t4g and older | Yes, for older-generation instances |
| Amazon DynamoDB | On-demand throughput (up to 18% savings); provisioned capacity (up to 12% savings) | DynamoDB Accelerator (DAX) | No — cannot combine with DynamoDB reserved capacity on same workload |
| Amazon ElastiCache | Valkey engine only — Gen 7+ provisioned and ElastiCache Serverless for Valkey | Standard Redis engine; Memcached engine | Yes, for standard Redis and Memcached |
| Amazon DocumentDB | Gen 7+ provisioned instances; DocumentDB Serverless | Older DocumentDB instance families | Yes, for older-generation instances |
| Amazon Neptune | Gen 7+ provisioned instances; Neptune Serverless | Older Neptune instance families | Yes, for older-generation instances |
| Amazon Neptune Analytics | Neptune Analytics instances (added March 2026) | No known exclusions | No — RIs not available for Neptune Analytics |
| Amazon Keyspaces | On-demand and provisioned throughput | No known exclusions | No — RIs not available for Keyspaces |
| Amazon Timestream | InfluxDB instances | LiveAnalytics usage type | No — RIs not available for Timestream |
| Amazon OpenSearch | Serverless usage AND provisioned instances (Gen 7+) — expanded March 2026 | Older provisioned OpenSearch instance families | Yes, for older-generation provisioned instances |
| AWS DMS | Gen 7+ replication instances; DMS Serverless | Older DMS instance families | Yes, for older DMS instance families |
Also read: AWS Savings Plans vs Reserved Instances
Which Instance Families and Configurations Are Eligible?
Amazon RDS and Aurora
Database Savings Plans apply to newer-generation RDS and Aurora instance families. AWS has confirmed eligibility for Gen 7 and newer families including db.m7, db.m7g, db.r7, and db.r7g. Older families including db.m5, db.r5, db.t3, and db.t4g are not eligible and continue to require Reserved Instances or migration to newer generations to access spend-based discounts.
For most engineering teams, this creates a useful forcing function. Newer instance families typically offer better price-to-performance than older generations, and the availability of spend-based commitments on Gen 7 and newer families gives teams a financial reason to accelerate upgrades that may have been deferred.
Amazon ElastiCache
For ElastiCache, coverage is limited to the Valkey engine, which is the Redis-compatible engine AWS introduced following licensing changes in the Redis project. Both provisioned clusters and serverless deployments on Valkey are eligible. Standard Redis and Memcached are not covered by Database Savings Plans and continue to require Reserved Nodes.
DynamoDB, Neptune, DocumentDB, and Other Services
For services like DynamoDB, Neptune, DocumentDB, Keyspaces, Timestream, and DMS, Database Savings Plans apply based on spend rather than configuration. Teams running variable throughput workloads, on-demand capacity modes, or multi-engine environments benefit most, as spend-based commitments provide coverage regardless of how usage patterns shift.
How Do AWS Database Savings Plans Differ From Reserved Instances?
The shift from configuration-specific Reserved Instances to spend-based Database Savings Plans introduces several meaningful changes in how AWS applies discounts to managed database workloads. Understanding these differences is essential for DB teams deciding how to structure long-term commitments.
| Factor | Reserved Instances | Database Savings Plans |
| Commitment basis | Specific instance class, engine, deployment type, and Region locked at purchase | Hourly spend amount only — no configuration lock |
| Flexibility | Breaks if instance, engine, or Region changes | Discount follows spend; routine changes do not break coverage |
| Maximum discount | Up to 40%+ for 3-year All Upfront (varies by service) | Up to 35% for serverless; up to 20% for provisioned instances |
| Term options | 1-year or 3-year | 1-year only (no 3-year option available) |
| Payment options | All Upfront, Partial Upfront, No Upfront | No Upfront only* |
| Coverage automation | Must match configuration exactly to apply | Applies automatically to all eligible usage |
| Eligible services | Broader — covers older instance generations | Narrower — Gen 7+ only for provisioned; specific engines only |
| Billing application order | Applied FIRST to matching eligible usage each billing hour | Applied SECOND, after RIs, to remaining eligible usage |
| Best for | Stable, predictable workloads on fixed instance types running for 1-3 years | Workloads that resize, migrate engines, or shift across services or Regions |
| Can be combined? | Yes — RIs and Database Savings Plans can coexist across different workloads | Yes — but cannot combine with RIs on the exact same workload |
Why Reserved Instances Break for Modern Database Environments
Reserved Instances require teams to specify, at purchase, the exact instance class, database engine, deployment type, and AWS Region. All four must match the running workload for the discount to apply. If any one changes, the Reserved Instance no longer applies and the team pays full on-demand rates until the RI expires.
Modern database environments regularly resize for performance, upgrade to newer instance generations, migrate between database engines, or shift from Single-AZ to Multi-AZ. Each of these is a routine infrastructure decision, but each can strand a Reserved Instance commitment and create unexpected cost exposure.
Database Savings Plans solve this by decoupling the discount from configuration. The committed spend follows actual usage rather than being tied to a specific setup that may change. For DB teams managing frequently evolving environments, this is the core value of the new model.
Why Database Savings Plans Matter for Managed Database Workloads
The benefits of spend-based database commitments are especially noticeable in environments that scale frequently, shift between deployment models, or evolve across instance generations.
Relational Databases Running on RDS and Aurora
For relational database teams, the ability to resize, migrate, or switch to serverless deployments without losing commitment coverage is a significant operational improvement. Previously, a team moving from a db.r5 to a db.r7 instance lost their Reserved Instance discount on the new configuration. With Database Savings Plans, committed spend continues to apply regardless of the instance generation upgrade.
Serverless and Key-Value Workloads
For serverless database deployments and DynamoDB workloads, applying spend-based discounts to on-demand and variable throughput usage provides savings in areas where commitment options were previously limited. Variable throughput patterns that made traditional RI commitment risky are now coverable with a spend-based approach.
In-Memory Caching Layers
For ElastiCache users running Valkey, the ability to move across instance generations without breaking discounts reduces operational overhead and lowers the risk of unused commitments. This is particularly relevant for teams running ElastiCache Serverless on Valkey, where capacity scales automatically and a fixed-instance RI would frequently be over or under-provisioned relative to actual demand.
Also read: How FabFitFun Saves $1 Million a Year on AWS Costs
What Changes for DB Teams Currently Using Reserved Instances?
For teams currently using RDS Reserved Instances, Database Savings Plans introduce a more flexible commitment option that better aligns with evolving workloads. Existing RIs continue to function normally for the remainder of their term. There is no immediate action required and no disruption to existing coverage.
The same considerations apply to workloads running on ElastiCache for Valkey, where usage patterns can shift due to scaling, throughput changes, or instance generation upgrades. In these cases, a spend-based commitment can provide more predictable coverage than configuration-specific RIs as workloads evolve.
Deciding whether to transition from RIs to Database Savings Plans at renewal depends on each workload’s behavior and refresh cycle. Teams should evaluate how often their databases resize, change capacity modes, or shift deployment models. If the answer is frequently, the flexibility of a spend-based commitment is likely worth the small discount difference compared to an RI. For a detailed comparison of the two commitment types across all relevant factors, the AWS Savings Plans vs Reserved Instances guide on Usage.ai covers the full decision framework.
What Is the Financial Impact of Database Savings Plans?
The exact savings from Database Savings Plans depend on the commitment term, payment option, and specific services running. The financial case is straightforward to model once you have accurate consumption data.
Discount Ranges
AWS Database Savings Plans can reduce managed database costs by up to 35% compared to on-demand pricing. For RDS and Aurora on eligible Gen 7 instance families, savings typically range between 30% and 35% depending on the term length and payment option. All Upfront commitments deliver the highest discount. The precise rates vary by service and instance family and should be confirmed in the AWS Savings Plans pricing calculator before purchasing.
| Deployment Model / Usage Type | Services | Maximum Savings vs On-Demand | Notes |
| Serverless deployments | Aurora Serverless v2, Aurora DSQL, ElastiCache Serverless for Valkey, DocumentDB Serverless, Neptune Serverless, OpenSearch Serverless | Up to 35% | Highest discount tier. Applies regardless of capacity consumed per hour. |
| Provisioned instances (Gen 7+) | Aurora, RDS, ElastiCache for Valkey, DocumentDB, Neptune, DMS, Timestream (InfluxDB) | Up to 20% | Applies to newer instance families only. Older families (m5, r5, r6g etc.) are not eligible. |
| On-demand throughput | DynamoDB, Keyspaces | Up to 18% | Covers on-demand read/write capacity units. First time DynamoDB on-demand throughput has a commitment-based discount path. |
| Provisioned throughput capacity | DynamoDB, Keyspaces | Up to 12% | Lowest discount tier. Applies to pre-provisioned read/write capacity units. Cannot be combined with DynamoDB reserved capacity on the same workload. |
The Cost of Getting Commitments Wrong
One of the strongest financial arguments for spend-based commitments is not the discount itself but the reduction in commitment error cost. When a Reserved Instance becomes stranded because an instance was resized or upgraded, the organization continues paying for the RI while also paying on-demand rates for the new configuration. Depending on the instance size and remaining term, a single stranded Reserved Instance can represent thousands of dollars in wasted spend.
Database Savings Plans significantly reduce this risk. Because the discount applies to spend rather than configuration, most routine database changes do not break coverage. For large database environments with frequent change, the avoided waste from stranded RIs can equal or exceed the small discount difference between the two commitment types.
What Do Database Savings Plans Mean for Usage.ai Customers?
Database Savings Plans immediately expand the commitment surface area that Usage.ai can optimize. Until now, database commitments were limited to configuration-specific Reserved Instances, which constrained how far automation could go for workloads that frequently shift engines, instance classes, or deployment models.
With spend-based commitments now available across multiple managed database services, Usage.ai applies the same automated coverage modeling and optimization logic used for compute Savings Plans directly to database environments. This gives customers a more adaptable commitment type for dynamic or multi-engine database footprints and reduces the operational overhead associated with tracking instance-specific commitments.
It also enables cleaner transitions at RI expiration windows, where Usage.ai can now evaluate Database Savings Plans as an alternative path for maintaining or improving coverage without requiring a like-for-like RI renewal.
Support for Database Savings Plans went live in Usage.ai in January 2026. Customers can evaluate and adopt this commitment model as part of their existing coverage workflows directly within the platform.
For a broader view of the cloud cost optimization principles that apply here, the cloud cost optimization guide on Usage.ai covers the foundational framework. To understand how AWS billing and cost management works at a base level before optimizing commitments, the AWS billing and cost management guide is a useful starting point.
Also read: How Usage.ai Works: RIs, SPs & Zero-Risk Savings
Practical Steps to Get Started with Database Savings Plans
If your team manages database workloads on AWS and wants to evaluate the new commitment model, here is a practical sequence to follow.
Step 1: Audit Your Current Database Inventory
Start by cataloging every managed database service running on AWS. For each workload, capture the service type, instance family and generation, database engine, deployment model, AWS Region, and current coverage status. This inventory gives you the foundation for a coverage gap analysis and identifies which workloads are candidates for spend-based commitments.
Step 2: Identify Eligible Workloads
Using your inventory, identify which workloads are eligible for Database Savings Plans. For RDS and Aurora, this means Gen 7 or newer instance families. For ElastiCache, this means Valkey deployments. For DynamoDB, Neptune, DocumentDB, Keyspaces, Timestream, and DMS, eligibility is broadly available across deployment types. Workloads that are not eligible need to remain on Reserved Instances or on-demand pricing.
Step 3: Analyze Consumption Patterns
For eligible workloads, analyze hourly consumption patterns over at least the past 90 days. This tells you how stable or variable your database spend is over time and what a reasonable commitment level looks like. Usage.ai automates this step using your AWS Cost and Usage Report data, eliminating the need for manual export analysis.
Step 4: Model Commitment Options
With consumption data in hand, model the financial impact of different commitment amounts, term lengths, and payment options. Evaluate the expected coverage ratio, projected savings, and financial risk at each commitment level. Manual modeling in spreadsheets is feasible for small environments but becomes unreliable as the number of services, Regions, and configurations increases. The best cloud cost management tools guide on Usage.ai covers the tooling options available for this kind of analysis.
Step 5: Purchase and Monitor
After selecting a commitment level, purchase through the AWS console or via the AWS API. Once purchased, monitor coverage levels regularly to confirm that actual usage aligns with committed spend. Usage.ai tracks this on an ongoing basis, alerting you when coverage gaps emerge and surfacing adjustment recommendations before they become cost issues.
Closing Thoughts
AWS’s move toward spend-based commitments for databases reflects a broader shift in how cloud infrastructure is built and operated. Databases are no longer static, single-configuration systems, and commitment models are finally catching up to that reality.
For DB teams, Database Savings Plans remove the core friction that made long-term database cost optimization difficult: the requirement to predict exactly what you will run, on which engine, in which Region, for the next one to three years. Spend-based commitments replace that prediction requirement with a simpler question: how much are you likely to spend?
That is a question most DB teams can answer with confidence. And with Usage.ai automating the analysis, modeling, and monitoring, it is a question that no longer requires a spreadsheet, a manual audit, or a quarterly RI review cycle to get right.
Frequently Asked Questions
1. What are AWS Database Savings Plans?
AWS Database Savings Plans are a spend-based commitment model for managed AWS database services. DB teams commit to a consistent hourly spend for one year and AWS automatically applies discounts to all eligible usage up to that amount. Unlike Reserved Instances, this commitment type is not tied to a specific instance type, engine, or Region, making it far better suited to environments where database configurations change over time.
2. Which AWS database services are covered?
The covered services include Amazon Aurora, Amazon RDS, Amazon DynamoDB, Amazon ElastiCache for Valkey, Amazon DocumentDB, Amazon Neptune, Amazon Keyspaces, Amazon Timestream, and AWS Database Migration Service. Standard Redis and Memcached on ElastiCache are not covered and continue to require Reserved Nodes. AWS has confirmed plans to expand the program as new services and configurations are added.
3. How much can DB teams save with Database Savings Plans?
AWS has indicated savings of up to 35% compared to on-demand pricing. Actual savings depend on the specific services running, the term length, and the payment option selected. All Upfront commitments deliver the deepest discount. Teams should use the AWS Savings Plans pricing calculator to model exact rates for their specific service and instance mix before committing.
4. Do Reserved Instances still work if I adopt Database Savings Plans?
Yes. Existing Reserved Instances continue to function normally for the remainder of their term with no disruption to current coverage. Database Savings Plans and Reserved Instances can be used simultaneously. For older RDS families not eligible for the new model, Reserved Instances remain the correct commitment vehicle.
5. Are Database Savings Plans available for DynamoDB on-demand capacity?
Yes. Spend-based database commitments apply to DynamoDB usage including on-demand and variable throughput workloads. This is a meaningful improvement over the previous commitment landscape, where DynamoDB Reserved Capacity required specific capacity unit commitments that did not adapt well to variable usage patterns.
6. What happens if my database usage exceeds my committed spend?
Usage above the committed hourly amount is charged at standard on-demand rates. There is no penalty for exceeding the commitment, but the excess usage does not receive a discount. Sizing the commitment accurately based on historical consumption patterns is the key step before purchasing to avoid unnecessary on-demand charges.
7. What happens if I commit more than I actually use?
If actual usage falls below the committed spend in a given hour, the committed amount is still charged and unused commitment does not roll over. Over-committing is a real cost risk, which is why modeling the right commitment level before purchasing is essential. Usage.ai automates this modeling using historical consumption data.
8. How does Usage.ai help with Database Savings Plans?
Usage.ai provides automated coverage modeling, consumption analysis, and commitment recommendations for both Database Savings Plans and Reserved Instances. The platform evaluates historical database spend, identifies eligible workloads, models optimal commitment levels, and monitors coverage over time, reducing the manual effort required to keep commitment coverage aligned with a changing database footprint.
9. When did AWS Database Savings Plans become available?
AWS announced general availability of Database Savings Plans at re:Invent in December 2024. This was the first time the Savings Plans model was extended to managed database services, after having been limited to compute workloads since its introduction in 2019.
10. When did Usage.ai add support for Database Savings Plans?
Usage.ai added native support for Database Savings Plans in January 2026. Customers can evaluate and adopt the new commitment model as part of their existing coverage workflows directly within the Usage.ai platform. Support for additional services including DynamoDB Keyspaces, Timestream, Neptune, and DocumentDB is planned for the same quarter.
