Cloudshipped

Blog

Database Savings Plans vs. Reserved Instances: Which Should a Startup Buy in 2026?

· 15 min read

A Reserved Instance assumes your database setup stays the same for the length of the term. At a startup it often doesn't. You move to Graviton, try Aurora Serverless v2, split out a service, or change engines, and the reservation stops matching what you're running.

In December 2025, AWS launched Database Savings Plans, a commitment that isn't tied to a specific instance configuration. RIs still show a deeper maximum discount, so the choice takes some working through.

My general take

For most startups, a Database Savings Plan tends to be the better fit. I'd lean toward Reserved Instances only for a database whose engine, instance family, and Region genuinely won't change for the full term. And if a migration or Graviton move is coming in the next few months, I'd usually hold off on either one until that settles.

The rest of this post covers the reasoning, the sizing method I use, and a worked dollar example you can check against your own bill. It's written for teams without a FinOps function, where a CTO or VP of Engineering owns the AWS bill alongside everything else and spends $10k or more a month.

Prices, discount rates, and dates below are accurate as of this writing. AWS changes pricing and terms, and your Region and account may show different numbers, so confirm current details on AWS's pricing pages before you buy anything.

What are AWS Database Savings Plans, and when did they launch?

AWS announced Database Savings Plans on December 2, 2025, at re:Invent. The model is the same one Compute Savings Plans use. You commit to a fixed amount of usage, measured in dollars per hour, for one year. AWS applies discounted rates to eligible database usage each hour until the commitment is used up, and anything above it bills at on-demand rates (AWS News Blog).

Note the phrase "eligible usage." You aren't reserving a specific database. You're committing to a spend level, and AWS decides each hour where to apply it.

Which services do Database Savings Plans cover, and how big is the discount?

At launch, the plans covered Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, and DMS in every commercial Region except China (AWS announcement). In March 2026, AWS added OpenSearch Service and Neptune Analytics. The current pricing page also lists Aurora DSQL and DMS Serverless.

Two caveats matter for startups:

  • ElastiCache is Valkey only. Redis OSS and Memcached clusters don't benefit (Savings Plans FAQ).
  • RDS for SQL Server gets a partial discount. It applies only to the instance price; Windows and SQL Server licensing stays at on-demand (pricing page).

The discount depends on what you run. AWS publishes these maximums (AWS News Blog):

Usage type Maximum Database Savings Plan discount
Serverless (Aurora Serverless v2, DocumentDB Serverless, etc.) Up to 35%
Provisioned instances Up to 20%
DynamoDB and Keyspaces on-demand throughput Up to 18%
DynamoDB and Keyspaces provisioned throughput Up to 12%

Read "up to" literally. If your stack is mostly provisioned Aurora instances, plan around something closer to 20%, and confirm the rate for your exact instance class on the pricing page before you buy.

Compare that with RDS Reserved Instances, which AWS says can save up to 69% over on-demand in steady state. On paper, RIs win on discount depth. That comparison leaves out what happens when your configuration changes, which the worked example below covers.

How are Database Savings Plans more flexible than RDS Reserved Instances?

A Database Savings Plan applies to eligible usage regardless of engine, instance family, size, deployment option, or Region. AWS's own examples, all of which keep the discount (Savings Plans FAQ):

  • Moving Aurora from db.r7g to db.r8g
  • Shifting a workload from Ireland to Ohio
  • Moving from RDS for Oracle to Aurora PostgreSQL
  • Moving from RDS to DynamoDB

An RDS Reserved Instance is tied to a specific configuration: engine, instance family, deployment type, and Region. Aurora, MySQL, MariaDB, PostgreSQL, Db2, and Oracle BYOL RIs do get instance size flexibility within a family, so a db.r7g.large reservation can cover part of a db.r7g.xlarge. That's the extent of it. Change the family, the engine, or the Region, and the RI stops matching.

Two more differences decide a lot of real cases:

  • Serverless: RIs are purchased per DB instance, so there's nothing to reserve for Aurora Serverless v2 capacity. A Database Savings Plan covers serverless, and serverless gets the biggest discount of any usage type.
  • Older instances: Database Savings Plans only cover Generation 7 and newer instances. If you're still on db.r5 or db.r6g, a Database Savings Plan won't cover that usage at all. RIs will.

What term and payment options do you get?

This is the one area where RIs still have more options.

The deepest RI discounts come from three-year, all-upfront purchases, which is exactly the commitment most Seed to Series B companies shouldn't be making on a database they'll likely resize twice in that window.

One rule applies to both: you can't stack them on the same workload. AWS says you can hold an RI on one workload and a Database Savings Plan on another, but not both discounts on the same usage (pricing page).

Database Savings Plans vs. Reserved Instances: side by side

Database Savings Plans RDS / Aurora Reserved Instances
What you commit to $/hour of eligible usage A specific DB instance configuration
Maximum published discount 35% serverless, 20% provisioned Up to 69%
Term 1 year 1 or 3 years
Payment No Upfront only No, Partial, or All Upfront (No Upfront on 1-year only)
Engine changes (e.g., RDS PostgreSQL to Aurora PostgreSQL) Discount follows the usage RI stops matching
Instance family changes (e.g., r7g to r8g) Discount follows the usage RI stops matching
Size changes within a family Covered Covered for size-flexible engines
Region changes Covered RI stops matching
Aurora Serverless v2 Covered, highest discount tier Not available
Other services (DynamoDB, ElastiCache Valkey, DocumentDB, etc.) Covered by the same commitment Separate reservations per service
Instance generations Gen 7 and newer only Older generations included
Stacking on the same workload No No

What happened when I switched from RIs to a Database Savings Plan?

At a previous company, we were running several Aurora clusters and buying RDS Reserved Instances one year at a time. The problem was that each RI purchase fixed our choice of RDS or Aurora and of instance type for the next twelve months. Any architecture change had to wait for the reservation to expire, or we'd pay for a reservation we weren't using.

We switched when Database Savings Plans launched. Our first plan let us try Aurora Serverless v2 on real workloads for autoscaling, without first checking whether the experiment would leave a reservation unused. The commitment followed the usage.

The plan saved us as much as the RIs had, or more. It also meant we could change database configurations without checking what we'd already prepaid.

How much Database Savings Plan should you commit to?

The usual guidance is "commit to 70 to 80% of your average spend." That rule has two problems:

  • It ignores your quiet hours. The commitment is applied hour by hour, and unused commitment in one hour doesn't roll over to the next (AWS re:Post). Averages hide the quiet hours, which is where unused commitment shows up. Size to the floor, not the average.
  • It confuses on-demand dollars with Savings Plans dollars. The commitment is measured at Savings Plans rates, not on-demand rates. In AWS's own example, a $10/hour commitment covered usage worth $12 at on-demand prices (AWS re:Post). If your floor is $5/hour of on-demand usage and you commit $5/hour, you've overcommitted.

The five-step sizing process

  1. Pull AWS's recommendation as a starting point. Use the 60-day lookback; the API offers 7, 30, or 60 days. From the CLI:

    aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type DATABASE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS

  2. Find your floor. That's the lowest sustained hourly on-demand spend on eligible database usage over those 60 days. Nights and weekends usually set it.

  3. Subtract what's leaving. Remove anything you plan to shut down, move off eligible services, or keep on an existing RI during the next 12 months.

  4. Convert to Savings Plans dollars by applying the discount for your usage mix.

  5. Model two sizes. Run that number and a smaller one through the Savings Plans Purchase Analyzer and compare utilization. Buy the amount that holds near-full utilization, then add a second plan later if coverage stays low. Two small plans sized correctly cost less than one large plan sized wrong.

Safety net: AWS lets you return a Savings Plan with an hourly commitment of $100 or less if it was purchased in the past 7 days and in the same calendar month (Savings Plans FAQ). Check your new plan's utilization in the first few days, not at the end of the month.

Step 3 is where most teams get stuck, because nobody can say what the database footprint will look like in six months. If you'd like a second look at your numbers, I do this as part of the Cloudshipped Cost Audit for AWS. You can book a free discovery call here.

What does the math look like for a real startup setup?

Every number below is a stated assumption, not an AWS price. Plug in your own.

The assumptions

  • A Series A company runs Aurora PostgreSQL on Graviton Gen 7 instances in one Region.
  • The 60-day hourly floor of eligible database usage is $4.00/hour at on-demand rates.
  • Database Savings Plan discount: 20% on provisioned instances and 35% on serverless (AWS's published maximums).
  • A 1-year No Upfront RI saves 30% on the same instances. That 30% is illustrative, not an AWS quote. The Aurora pricing page lists the effective hourly RI rate for each instance class, term, and payment option, so use the real figure for yours.

On-demand for the year: $4.00 × 8,760 hours = $35,040.

Scenario A: nothing changes for 12 months

  • RI: $4.00/hour covered at $2.80/hour, so $24,528 for the year. Saves $10,512.
  • Database Savings Plan: commitment of $4.00 × 0.80 = $3.20/hour, so $28,032 for the year. Saves $7,008.

The RI wins by $3,504. If you're certain nothing will change, this is the case for RIs.

Scenario B: in month 4, half the workload moves to Aurora Serverless v2

Half the workload ($2.00/hour on-demand) moves to Aurora Serverless v2.

  • RI: keeps billing $2.80/hour all year, $24,528, but half of it now matches nothing. The moved workload runs serverless at on-demand: $2.00 × 5,840 remaining hours = $11,680. Total: $36,208. That's $1,168 more than never buying anything.
  • Database Savings Plan: keeps working. The remaining provisioned usage costs $1.60/hour at Savings Plans rates and the serverless usage costs $1.30/hour, for $2.90/hour against a $3.20 commitment. You pay the $3.20 commitment, $28,032 for the year, and still save $7,008.

One architecture change in month 4 swung the RI from a $10,512 saving to a $1,168 loss.

The same thing happens if you move from r7g to r8g, change engines, or change Regions. RIs come out ahead only when your configuration holds for the full term, and most startups I talk to can't promise that for their primary database.

So which should a startup buy?

Buy a Database Savings Plan when any of these are true

  • You run Aurora Serverless v2 or plan to.
  • You expect to change instance families or engines within a year.
  • You use several covered services (Aurora plus DynamoDB plus ElastiCache Valkey, for example).
  • You're on current-generation instances and want one commitment to manage instead of a spreadsheet of reservations.

Buy RIs when the database won't change

  • Same engine, same family, same Region for the full term.
  • You have pre-Gen 7 instances you can't migrate yet, since the Database Savings Plan won't cover them.
  • Your finance team wants a three-year or upfront commitment. RIs are the only way to get one.

Mix them when one large stable database sits among changing workloads

AWS's own FAQ describes this pattern: an RI covering db.r5 instances for Aurora MySQL, with a Database Savings Plan covering db.r8g and serverless usage for Aurora PostgreSQL (Savings Plans FAQ). Size the plan after you subtract the RI-covered usage, because the two won't stack on the same workload.

If you already hold RIs, let them run out. Don't layer a plan on top of usage the RI is already covering.

When should you buy nothing yet?

Sometimes the right answer is to buy neither. Skip the commitment if:

  • You have less than two to three months of stable usage history. The recommendation will reflect a footprint that doesn't exist anymore.
  • A major database migration is on the roadmap in the next quarter, whether that's RDS to Aurora, self-managed to managed, or a Region move.
  • You're about to move to Graviton or a newer instance generation.

The Graviton case

If you're on db.r5 or db.r6g today, an RI on that family locks you into the old hardware for a year or three, and a Database Savings Plan won't apply to it at all. Do the migration first, let usage settle for a few weeks, then buy a Database Savings Plan sized to the new, smaller floor. I cover the Graviton migration path in migrating EKS to Graviton with Karpenter.

Waiting a quarter costs you about a quarter of the discount. Buying before a migration can leave you paying for an unmatched reservation for up to a year.

If you want help working out which bucket your account falls into, I run a fixed-scope Cloudshipped Cost Audit for AWS. Book a free discovery call and we'll look at your actual database spend.

FAQ

Can I use a Database Savings Plan and RDS Reserved Instances at the same time?

Yes, across different workloads. AWS doesn't let both discounts apply to the same workload, but you can hold an RI on one database and let a Database Savings Plan cover the rest. For DynamoDB, AWS applies reserved capacity first, then Database Savings Plans cover any remaining eligible usage.

Do Database Savings Plans cover Aurora Serverless v2?

Yes. Serverless usage, including Aurora Serverless v2, is covered, and it gets the largest discount AWS publishes for the plan: up to 35% off on-demand. There's no Reserved Instance for Aurora Serverless v2 capacity, so a Database Savings Plan is the only commitment discount available for it.

Is there a 3-year Database Savings Plan?

Not as of this writing. AWS offers Database Savings Plans on a one-year term with no upfront payment only. If you want a three-year commitment or an upfront payment option for RDS or Aurora, Reserved Instances are still the only way to get one. Check the pricing page before buying, since AWS may add terms.

How do I get a Database Savings Plan recommendation?

Open the Savings Plans recommendations in the Billing and Cost Management console and select Database Savings Plans, or run aws ce get-savings-plans-purchase-recommendation with --savings-plans-type DATABASE_SP. Lookback options are 7, 30, or 60 days. Treat the output as a ceiling, then subtract planned migrations and resizes before buying.

Disclaimer

This article is general information about AWS cost optimization, not financial, tax, or legal advice for any specific AWS account. AWS pricing, discount rates, terms, and feature availability change over time and vary by Region and account, so confirm current details directly with AWS before acting. You're responsible for testing and validating any change in a non-production environment before applying it to production. Cloudshipped isn't liable for costs, outages, or losses that result from actions taken based on this article. Cloudshipped is an independent consultancy and isn't affiliated with or endorsed by Amazon Web Services.

Sources

Free discovery call

Find the savings your AWS bill is hiding

Book a free discovery call to see how Cloudshipped can help save you money on AWS spend.

  • Fixed price
  • 1-week target
  • Fee refunded if under 10%
Book a free Discovery Call

Prefer email? Write to support@cloudshipped.co