In a customer conversation last week, a FinOps lead asked a question that’s now common across AWS accounts: “We have $400,000 in RDS Reserved Instances across R5 and R6 families. AWS just launched Database Savings Plans. Should we migrate?” 

AWS announced Database Savings Plans at re:Invent 2025, extending the flexible Savings Plans model to managed database services for the first time. For organizations running Amazon RDS, Aurora, DynamoDB, and other AWS databases, this represents the most significant pricing change since RDS Reserved Instances launched over a decade ago.

The challenge? Database Savings Plans don’t simply replace Reserved Instances. They cover different instance generations, offer different discount rates, and work best for different workload patterns. Teams rushing to migrate without understanding these distinctions risk leaving money on the table—or worse, committing to inflexible spend that doesn’t match their actual usage.

This guide explains exactly when to use Database Savings Plans versus RDS Reserved Instances, how to migrate existing commitments without coverage gaps, and which common mistakes to avoid based on real customer scenarios. 

What Are AWS Database Savings Plans?

Database Savings Plans are a commitment-based discount model that reduces AWS managed database costs by up to 35% in exchange for committing to a consistent hourly spend ($/hour) over a 1-year term. For a full guide, check out AWS Database Savings Plans, Part 1. 

Unlike RDS Reserved Instances, which lock you into a specific instance type, family, size, and region, Database Savings Plans automatically apply to eligible usage across:

  • 14 database services: Amazon Aurora, RDS (all engines), DynamoDB, ElastiCache (Valkey only), DocumentDB, Neptune, Keyspaces, Timestream, and Database Migration Service.
  • Any AWS Region: Commitments apply globally. Shift workloads from us-east-1 to eu-west-1 and keep the discount
  • Any instance family or size: Upgrade from db.r7g.large to db.r8g.xlarge without buying new commitments
  • Any database engine: Migrate from RDS MySQL to Aurora PostgreSQL or DynamoDB, and the discount follows

You commit to spending $X per hour on database usage. Every hour, AWS automatically applies your commitment to eligible usage at the discounted rate. Usage beyond your commitment is billed at on-demand rates.

Example: You commit to $100/hour for Database Savings Plans. In a given hour, you have $120 of eligible database usage. AWS applies the 20% discount to the first $100 (you pay $80 for that portion), and the remaining $20 is billed at on-demand rates. Your effective hourly cost is $100 instead of $120.

Note: Database Savings Plans are 1-year term only, no upfront payment only. There’s no 3-year option and no partial or full upfront payment tiers. This limits maximum discount depth compared to 3-year RDS Reserved Instances.

AWS Database Savings Plans vs RDS Reserved Instances: Key Differences

Understanding when to use Database Savings Plans versus RDS Reserved Instances requires knowing exactly how they differ. Which commitment type is best depends on your specific workload characteristics.
DimensionDatabase Savings PlansRDS Reserved Instances
Commitment model$ per hour (e.g., $50/hr)Specific instance type (e.g., 10× db.r6g.xlarge)
Term length1 year only1 year or 3 years
Payment optionsNo upfront onlyNo upfront, Partial upfront, Full upfront (higher discount)
Instance flexibilityFull: any instance family, size, regionSize-flexible within family (e.g., R5 → R5 any size), but locked to family & region
Service coverage14 database servicesRDS only (cannot cover DynamoDB, ElastiCache, etc.)
RDS instance generation coverageGen 7 and 8 only All generations including Gen 5 and 6
Discount rate (provisioned RDS)20% flat discount30–42% for Gen 6 (1yr No Upfront), higher with 3yr or upfront payment
Discount rate (serverless)35% (Aurora Serverless, DocumentDB Serverless, ElastiCache Serverless)Not available for serverless
DynamoDB coverageYes, on-demand (18%) and provisioned (12%)No, DynamoDB uses separate Reserved Capacity model
Licensed engines (SQL Server, Oracle)Covers compute only (BYOL), full flexibility across sizes/regionsCovers compute + license (if bundled), or BYOL with size lock-in
Best forFlexible workloads, multi-service portfolios, migrations, serverlessStable single-service workloads, older instance generations, maximum discount depth

How AWS Database Savings Plans Work

Database Savings Plans use the same hourly commitment application model as Compute Savings Plans. Understanding the mechanics prevents common coverage and utilization mistakes. In this section, we’ll break down how they apply, what services are covered, and common frustrations with DSPs.

Hourly Commitment Application

Every hour, AWS evaluates your eligible database usage and applies your Database Savings Plans commitment in this order:

  1. Identify eligible usage: All usage from covered services (Aurora, RDS Gen 7+, DynamoDB, ElastiCache Valkey, etc.) in the hourk
  2. Sort by discount value: AWS automatically prioritizes applying the commitment to usage with the highest absolute $ discount (not highest % discount)
  3. Apply commitment up to limit: Discount applied until your $/hr commitment is exhausted
  4. Remaining usage billed on-demand: Anything beyond the commitment is billed at regular rates

Example: Multi-Service Portfolio

In a given hour, you have:

  • $80 of Aurora Serverless usage (35% discount potential = $28 savings)
  • $60 of RDS db.r7g usage (20% discount potential = $12 savings)
  • $40 of DynamoDB on-demand usage (18% discount potential = $7.20 savings)

Total eligible: $180. You have a $100/hr Database Savings Plan commitment.

AWS applies the commitment prioritizing highest absolute dollar savings:

  1. $80 to Aurora Serverless (saves $28, commitment now $20 remaining)
  2. $20 to RDS db.r7g (saves $4, commitment exhausted)
  3. Remaining $40 RDS + $40 DynamoDB billed on-demand

Your hourly cost: ($80 – $28) + ($20 – $4) + $40 + $40 = $148 instead of $180.

Instance Generation Constraint: Gen 7+ Only

The most common Database Savings Plans frustration: existing RDS fleets on Gen 5 and Gen 6 instances are not eligible.

Eligible instance families:

  • M instances: db.m7g (Graviton3), db.m7i (Intel), db.m8g (Graviton4)
  • R instances: db.r7g (Graviton3), db.r7i (Intel), db.r7gd (local NVMe), db.r8g (Graviton4)
  • X instances: db.x2g (Graviton2 for in-memory), db.x8g (Graviton4)

Not eligible: 

  • db.m5, db.m6g, db.m6i, db.r5, db.r6g, db.r6i, db.t3, db.t4g, or any older generation.

This means that a fleet with 80% of spend on db.r6g and 20% on db.r7g will only have the 20% portion qualify for Database Savings Plans, and in many cases migrating to Gen 7 solely to become eligible costs more than the savings you’d capture (see the calculation above). As a result, teams often end up using hybrid strategies—keeping RIs for Gen 6 workloads while applying Database Savings Plans to Gen 7 usage.

DynamoDB Coverage: On-Demand and Provisioned

For the first time, DynamoDB on-demand throughput (pay-per-request) has a commitment savings option. Previously, only provisioned capacity had Reserved Capacity pricing.

Database Savings Plans discounts for DynamoDB:

On-demand throughput: 18% off read/write request units

Provisioned capacity: 12% off read/write capacity units

This matters for spiky, serverless-first workloads where Reserved Capacity wasn’t practical.

Covered Services: The Full List

Database Savings Plans automatically apply to these 14 services:

  1. Amazon Aurora (MySQL, PostgreSQL, Serverless v2, DSQL)
  2. Amazon RDS (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, Db2)
  3. Amazon DynamoDB (on-demand and provisioned)
  4. Amazon ElastiCache (Valkey only, provisioned and serverless)
  5. Amazon DocumentDB (provisioned and serverless)
  6. Amazon Neptune (provisioned and serverless)
  7. Amazon Keyspaces (Apache Cassandra)
  8. Amazon Timestream (instance-based InfluxDB only, not serverless LiveAnalytics)
  9. AWS Database Migration Service (provisioned and serverless)

Not covered: Athena, MemoryDB, Redshift, SimpleDB, ElastiCache Redis/Memcached.

When to Use Database Savings Plans vs Reserved Instances

The decision framework comes down to four factors: instance generation, workload stability, commitment flexibility needs, and service diversity.

Use Database Savings Plans when:

  1. Running Gen 7 or Gen 8 instances: especially Graviton-based db.r7g or db.m7g where RI discounts are 8–10% lower than older generations
  2. Migrating between engines or services: moving from RDS MySQL to Aurora PostgreSQL, or RDS to DynamoDB, or consolidating multi-service database spend under one commitment
  3. Using serverless databases: Aurora Serverless, DocumentDB Serverless, and ElastiCache Serverless get 35% discounts (RIs not available for serverless)
  4. Running licensed engines with size flexibility needs: Microsoft SQL Server or Oracle where you want to resize instances without buying new RIs
  5. Short commitment horizon: uncertain about 3-year usage patterns, prefer 1-year flexibility
  6. DynamoDB on-demand workloads: spiky traffic patterns, pay-per-request mode, want 18% savings without Reserved Capacity lock-in

Use RDS Reserved Instances when:

  1. Running Gen 5 or Gen 6 instances: db.r5, db.r6g, db.m5, db.m6i are not eligible for Database Savings Plans; RIs are the only commitment option
  2. Stable, predictable workloads: same instance size, engine, and region for 1–3 years; willing to accept size lock-in for deeper discounts (30–42% vs 20%)
  3. Maximizing discount depth: 3-year Partial or Full Upfront RIs deliver 45–55% savings, significantly higher than 20% Database Savings Plans
  4. Single-service RDS usage: all spend is RDS, no DynamoDB/ElastiCache/DocumentDB to benefit from cross-service flexibility
  5. License-included engines with stable sizing: SQL Server or Oracle (license-included) where instance size is fixed by application requirements

Hybrid strategy (use both):

According to nOps anonymized proprietary data, mid-market and enterprise organizations (500+ employees, $200k+ annual database spend) typically benefit from a hybrid approach:

  1. RIs for stable Gen 6 RDS workloads: production databases that won’t change for 1–3 years
  2. Database Savings Plans for Gen 7+ and serverless: newer workloads, development/staging environments, multi-service portfolios
  3. On-demand for experimental workloads: new projects, proof-of-concepts, temporary environments

This maximizes discount coverage (60-80% of total spend) while maintaining flexibility for the unpredictable portion.

Real Customer Scenario: When NOT to Migrate

A FinOps team managing $800,000 in annual RDS spend across 40 instances asked: “Should we migrate our RIs to Database Savings Plans?”

Their fleet:

  • 30 db.r6g instances (Gen 6): $600,000 annual on-demand cost
  • 10 db.r7g instances (Gen 7): $200,000 annual on-demand cost

Current coverage:

  • 30 db.r6g covered by 1-year No Upfront RIs (35% discount): effective cost $390,000
  • 10 db.r7g running on-demand: cost $200,000
  • Total annual cost: $590,000 (26% overall savings)

If they migrate to Database Savings Plans:

  • db.r6g not eligible (Gen 6): would be on-demand at $600,000 unless upgraded
  • db.r7g eligible for 20% discount: effective cost $160,000
  • Total annual cost: $760,000 (5% overall savings)

The result? Migrating would increase annual costs by $170,000 because most of the fleet is Gen 6, which Database Savings Plans don’t cover.

A better strategy would be to keep existing RIs for Gen 6, and purchase Database Savings Plans only for the Gen 7 portion ($200,000 × 20% = $40,000 annual savings). Then re-evaluate RIs vs. Database Savings Plans as Gen 6 instances reach end-of-life.

How to Move from RDS RIs to DSPs: A Migration Tree

Migrating from RDS Reserved Instances to Database Savings Plans requires modeling impact, planning RI expiration, and avoiding coverage gaps.

Step 1: Inventory your current RDS fleet by instance generation

Run this AWS CLI command to list all RDS instances with their families:

aws rds describe-db-instances –query ‘DBInstances[*].[DBInstanceIdentifier,DBInstanceClass,Engine]’ –output table

Group the results:

  • Gen 5–6: db.m5, db.m6g, db.r5, db.r6g, db.t3, db.t4g → only eligible for RIs
  • Gen 7–8: db.m7g, db.m7i, db.r7g, db.r7i, db.r8g → eligible for Database Savings Plans

Then calculate the percentage of total spend in each group using Cost Explorer filtered by instance type.

Step 2: Calculate breakeven discount rate

For each RDS workload currently covered by an RI:
  • Note the current RI discount rate (from your RI purchase confirmation or Cost Explorer RI Utilization report)
  • Note the RI expiration date
  • Calculate: Breakeven rate = Current RI discount %

If the current RI discount is greater than 20%, Database Savings Plans will typically save less money unless the workload benefits meaningfully from cross-service flexibility.

Step 3: Model three scenarios

Use the AWS Savings Plans Purchase Analyzer (Billing Console → Savings Plans → Purchase Analyzer):

  1. Scenario A: Keep all existing RIs — Let them renew at current rates
  2. Scenario B: Migrate Gen 7+ to Database Savings Plans — Purchase Database Savings Plans for eligible instances, keep RIs for Gen 6
  3. Scenario C: Full migration — Upgrade Gen 6 to Gen 7 hardware and consolidate under Database Savings Plans

The Purchase Analyzer shows projected savings, coverage percentage, and utilization percentage for each scenario based on your last 7, 30, or 60 days of usage.

Step 4: Migrate incrementally

Do not cancel existing RIs (they are non-refundable). Instead, layer Database Savings Plans as RIs expire:

  • 30 days before RI expiration: Decide whether to renew the RI or shift to Database Savings Plans
  • If migrating: Purchase a Database Savings Plans commitment matching the expiring RI’s hourly coverage (calculated as: on-demand cost × [1 – discount %])
  • Track in a migration calendar with RI ID, expiration date, covered instance type, and renewal decision

This approach prevents double-paying for commitments and avoids coverage gaps during the transition.

Avoiding Common DSP Migration Mistakes

Based on customer conversations, we share common Database Savings Plans pitfalls (in addition to the ones we already covered, such as Instance Generations not being covered). 

Mistake 1: Migrating before RIs expire

You can’t cancel or get refunds on Reserved Instances. Purchasing Database Savings Plans while RIs are still active means you’re paying for both commitments simultaneously. Wait until 30 days before RI expiration to make the migration decision.

Mistake 2: Forgetting to account for license costs

For licensed engines (SQL Server, Oracle with license-included), RIs cover both compute and license costs. Database Savings Plans cover compute only. If you migrate from an RI to Database Savings Plans for a license-included instance, you’ll start paying on-demand license fees—potentially wiping out savings.

Mistake 3: Over-committing based on peak usage

A common error is purchasing Database Savings Plans sized to cover peak hourly usage. Since commitments are hourly (not monthly or yearly), this leads to low utilization rates.

Better approach: size commitments to cover 60–70% of typical usage, and let peak hours run on-demand. For example:

  • Avg hourly database spend: $150/hr
  • Peak hourly spend: $220/hr
  • Recommended commitment: $100–105/hr (covers 67–70% of average, 45–48% of peak)
  • Achieves 85–90% utilization and avoids over-commitment

Mistake 4: Assuming DSPs are better than RIs, i.e. flexibility is always better

The reality is that flexibility comes at a cost. Database Savings Plans deliver smaller discounts for RDS provisioned instances than long-term RIs. For stable, long-running production databases, RIs often deliver significantly higher savings.

The fix is to treat flexibility as a feature you pay for. If you don’t need to change instance families, regions, or engines, RIs usually deliver better economics. Reserve Database Savings Plans flexibility for workloads that actually need it (migrations, multi-service portfolios, development environments).

Mistake 5: Mixing Database Savings Plans with RDS RIs on the Same Workload

Imagine a team has existing RIs covering 50% of an RDS instance’s usage, then purchases Database Savings Plans hoping to cover the remaining 50%.

The problem is that you can’t “stack” both discounts on the same usage. AWS applies RIs first, then Database Savings Plans to any uncovered usage. If an RI already covers 100% of an instance’s usage, Database Savings Plans won’t apply to it.

Fix: Track RI expiration dates. Let RIs expire fully before migrating to Database Savings Plans, or use Database Savings Plans only for workloads not covered by existing RIs.

Mistake 6: Ignoring utilization and coverage metrics

After purchasing Database Savings Plans, teams forget to check whether the commitment is actually being used.

Low utilization means you’re paying for committed spend that isn’t applying to usage (wasted money). Low coverage means most of your database spend is still on-demand (missed savings opportunity).

Fix: Track your Effective Savings Rate.

What nOps Does for Database Savings Plans

Here at nOps, we’ve helped many customers get the most value out of their DSPs, with:

1. Intelligent Hybrid Commitment Management

nOps automatically determines the optimal split between Database Savings Plans and RDS Reserved Instances based on your actual workload patterns:

  • Gen 6 instance coverage: nOps identifies which workloads qualify for RIs and purchases them automatically when they deliver higher savings than on-demand.
  • Gen 7+ and serverless coverage: For eligible instances and serverless databases, nOps evaluates whether Database Savings Plans or RIs deliver better ROI based on your usage volatility.
  • DynamoDB optimization: nOps analyzes on-demand vs. provisioned capacity patterns and recommends Database Savings Plans when your DynamoDB spend justifies commitment (typically a $500+/month threshold).

Here’s a real customer example. A SaaS company had $80k/month RDS spend split across 60% Gen 6 (db.r6g) and 40% Gen 7 (db.r7g). nOps automatically purchased

  • 1-year RIs for Gen 6 stable production instances (35% discount)
  • Database Savings Plans for Gen 7 development/staging instances (20% discount + flexibility)

The result was 32% blended savings vs. 18% if they’d tried only Database Savings Plans or only RIs.

2. Migration-Aware Commitment Planning

nOps continuously monitors roadmap signals (instance upgrades, serverless migrations, multi-region expansions) and helps prevent common commitment mistakes:

  • Upgrade detection: If you’re migrating from db.r6g to db.r7g over the next 6 months, nOps avoids purchasing 1-year RIs that may become unused mid-term—recommending shorter-term options or Database Savings Plans that carry forward automatically.
  • Serverless transition modeling: Planning to move Aurora provisioned to Aurora Serverless v2? nOps models discount-rate differences (20% provisioned vs. 35% serverless) and recommends the right $/hr DSP commitment to maintain coverage through the migration.
  • Service migration flexibility: Moving from RDS MySQL to Aurora PostgreSQL? DSPs can cover both. nOps ensures commitment sizing accounts for the shift without manual recalculation.

3. Expiration Calendar and Renewal Automation

Every RI expiration requires a decision: renew as RI, switch to Database Savings Plans, or let it lapse. nOps helps automate those decisions with usage trend analytics. For example, nOps detects when a previously stable workload has decreased 30%+ over the last 6 months and recommends not renewing—or purchasing a smaller DSP commitment instead.

4. Multi-Service Portfolio Optimization

Database Savings Plans cover multiple database services. Tracking which services consume your commitment (and where spend stays on-demand) is difficult manually. nOps provides:

  • Hourly commitment utilization tracking: See exactly which services (Aurora, RDS, DynamoDB, ElastiCache) consumed your DSP commitment each hour, and where coverage gaps exist.
  • Waste detection: nOps flags hours where commitment goes partially unused (e.g., usage drops to $80/hr but you’re committed to $100/hr) and models whether downsizing would be more cost-effective.
  • Recommended commitment adjustment: Based on 90-day rolling trends, nOps increases or decreases commitment at renewal to match real usage patterns.

The Bottom Line

Here’s why teams choose nOps to manage their Database Savings Plans (and other multicloud commitments). 

Zero-risk pricing model: nOps uses savings-based pricing. You pay a percentage of the savings delivered, with no upfront cost. If nOps doesn’t save you money, you don’t pay.

Proven at scale: nOps manages $3B+ in cloud spend across 500+ customers and was rated #1 in G2’s Cloud Cost Management category. Customers typically see 15–30% database savings within the first 90 days.

Set-it-and-forget-it automation: Once connected, nOps runs continuously. Optimization runs autonomously each hour without any intervention required on your part.

Want to see how much nOps could save on your AWS database spend? Book a free savings analysis, no commitment required.

Frequently Asked Questions

What discount rates do Database Savings Plans offer?
Database Savings Plans offer up to 20% off provisioned database instances and up to 35% off serverless usage, depending on the service. DynamoDB receives smaller discounts. Discounts apply automatically to eligible usage up to your hourly commitment; any usage beyond that is billed at on-demand rates.
Yes, but they cannot apply to the same usage. AWS applies RIs first, then Database Savings Plans to any remaining eligible usage. You cannot “stack” both discounts on one workload. Many teams use RIs for stable workloads and Savings Plans for flexible or multi-service usage.
No. Database Savings Plans only discount compute and serverless throughput. Storage, backup, data transfer, IOPS, and replication charges remain on-demand. If your RDS bill includes significant storage or backup costs, only the compute portion is eligible for Savings Plans discounts.