AWS Database Savings Plans: Commit to Spend, Not Shape

You want to move a production database from db.r7g to the newer db.r8g, or migrate an aging RDS-for-Oracle instance onto Aurora PostgreSQL. The engineering is clear. What stops you is the Reserved Instance you bought eight months ago — it’s locked to the old engine, the old instance family, the old region, and switching means eating the remaining commitment or forfeiting the discount. So the migration sits in the backlog, and you keep paying to not modernize.

That trade-off is exactly what AWS Database Savings Plans, announced December 2, 2025, were built to remove. The shift is small on paper and large in practice: you stop committing to a shape (engine + family + region) and start committing to a spend (dollars per hour). Here’s the commitment math we’d actually run, and — the part the launch post skips — where a plain Reserved Instance still beats the new plan.

What actually changed

An RDS Reserved Instance is a bet on specifics. To get the discount you had to name the engine, the instance family and size, the region, and — for some engines — the deployment option, then hope none of it changed for one to three years. Right-size mid-term and you were paying for capacity you’d stopped using. That rigidity was a real tax on doing the right engineering.

A Database Savings Plan is a bet on a number. You commit to a consistent hourly dollar amount, and AWS applies the discount automatically to eligible database usage — regardless of engine, instance family, size, deployment option, or region. Usage above the commitment bills at on-demand rates, and No Upfront is the only payment option — unlike an RDS Reserved Instance, there’s no partial- or all-upfront tier you can buy for a deeper rate. Coverage started at nine services at launch and has grown since — AWS added Amazon OpenSearch Service and Amazon Neptune Analytics on March 5, 2026. Today it spans Aurora, RDS, DynamoDB, ElastiCache (the Valkey engine only — Redis and Memcached still need Reserved Nodes), DocumentDB, Neptune and Neptune Analytics, Keyspaces, Timestream, AWS DMS, and Amazon OpenSearch Service. That the list keeps expanding is part of the point: a plan you buy this year automatically starts covering the services AWS adds next.

The concrete payoff is that the migrations above no longer cost you your discount. AWS’s own examples: you can move from db.r7g to db.r8g, shift a workload from EU (Ireland) to US (Ohio), or modernize from RDS for Oracle to Aurora PostgreSQL — and the discounted rate follows the spend across all of it. You commit to what you’ll spend, not to what it’ll look like.

The discount tiers reward modernizing, not sitting still

Here’s the part that changes how you plan. The savings are not flat across deployment types — as of the December 2025 launch:

Serverless (Aurora Serverless v2, etc.) — up to 35%
Provisioned instances — up to 20%
DynamoDB / Keyspaces on-demand throughput — up to 18%
DynamoDB / Keyspaces provisioned capacity — up to 12%

All on a 1-year term (there is no 3-year Database Savings Plan), available in all regions outside China. One quiet milestone: DynamoDB on-demand throughput is discountable at all now — previously only provisioned capacity could be committed.

Read the tiers as ceilings, not flat rates — the “up to” is doing real work. 35% is the Aurora/RDS serverless rate. ElastiCache, Neptune, and DocumentDB serverless land closer to 30%; DMS and OpenSearch serverless nearer 20%. Only the 20% provisioned tier is genuinely consistent across services, so price a specific mix against the Database Savings Plans pricing page, not the headline number.

One eligibility catch can quietly undo the math: provisioned instances must be current-generation. For the instance-based services — RDS, Aurora, Neptune, DocumentDB, DMS, OpenSearch — the discount only reaches Gen 7 families and newer (db.r7g, db.r8g, db.m7, and up). A fleet still on m5, r5, or even r6g gets nothing from a Database Savings Plan until it modernizes; those instances still need Reserved Instances. Buy to a floor that’s mostly last-gen hardware and you’ll find most of it was never eligible. (Neither plan touches AWS’s Extended Support surcharges on end-of-life engine versions, either — another line item that only goes away by upgrading.)

Read the serverless tier with an architect’s eye. The deepest discount lands on the deployment model that already scales to zero and bills for what you use. Reserved Instances still pay you the most for holding a fat provisioned instance still for three years — that incentive hasn’t inverted; it’s now got a flexible alternative alongside it that rewards modernizing (serverless, Graviton, engine consolidation) instead of freezing a fleet to protect a discount. Part of that 35% headline just reflects that serverless had no commitment discount at all until this launch — less “AWS pays a premium for modern,” more “the option finally exists.”

The mental model to carry into the math: this lever gets better as you improve the architecture underneath it — as long as the fleet is current enough to qualify.

The commitment math we’d actually run

The failure mode with any commitment-based discount is covering usage you won’t have. We wrote about this for Compute Savings Plans and the same discipline applies here: commit to the floor, leave the burst on-demand.

Right-size first, then commit. Buying any Savings Plan on top of oversized infrastructure just locks in paying for waste. Pull the last few weeks of database CloudWatch metrics, drop the obviously idle instances a size, and only then look at what’s left. A commitment is a floor under your steady state, not a substitute for right-sizing.
Find the steady-state baseline, not the peak. Look at your combined eligible database spend over the last 60–90 days and find the level it essentially never drops below. That reliable trough — not the monthly average, and definitely not the peak — is what you commit to. Everything above it bills on-demand, which is fine: the whole point is that you’re not penalized for the variable top. One mechanical wrinkle to keep in mind: a Database Savings Plan applies to your highest-discount-rate eligible usage first, then rolls down — it drains into Aurora Serverless before provisioned RDS before DynamoDB. You’re not modelling a blended average against a blended floor; you’re modelling a waterfall.
Commit conservatively and layer. Because every plan is No Upfront and the term is only a year, you can start below your estimated floor and add a second plan once you’ve watched real usage. Under-committing costs you a little discount on covered hours; over-committing means paying a discounted rate for database time you’re not using. The asymmetry favors caution — and if you do overshoot, Savings Plans can be returned within 7 days of purchase (subject to limits: up to $100/hour, within the same calendar month, and a periodic return quota), so an early commitment isn’t a one-way door.
Then modernize freely. Once the plan covers your floor, the migrations you’d been deferring — Graviton, engine consolidation, serverless — no longer threaten the discount. Do them. Each one that moves you toward serverless can also move you toward the deeper 35% tier.

The order matters as much as any single step — the same right-size-then-commit sequence we walk through in our AWS cost-cutting checklist.

The trap AWS’s own recommendation won’t flag

If you’re on a service-specific Private Pricing Agreement, read this before you buy anything. A Database Savings Plan and a service-specific PPA both discount the list rate, and only one can apply to a given unit of usage. Because the plan covers your highest-discount usage first, it can land on usage a PPA was already discounting more deeply — and displace it, leaving you with less total savings than before. A worked example from a published pricing analysis shows a customer with a 40% Aurora PPA dropping from roughly $30K to roughly $21.5K in annual savings after buying a Database Savings Plan. Worse, AWS’s console recommendations don’t account for service-specific PPAs, so the savings number it shows you can be optimistic.

Cross-service PPAs are fine — the Savings Plan applies first, then the PPA discounts the remaining balance. It’s specifically the service-specific ones that get crowded out. If you have any PPA in place, model the interaction before committing.

Where a Reserved Instance still wins

The Savings Plan is more flexible, but flexibility isn’t free — and this is the honest trade-off the launch announcements don’t dwell on. For a genuinely frozen fleet — a database you know the shape of and won’t touch for years — a Reserved Instance still buys a much deeper cut.

A 3-year, all-upfront RDS Reserved Instance on current Graviton (db.r8g) instances runs roughly 50–65% off on-demand, and it varies a lot by engine — MySQL and PostgreSQL sit nearer the low end, while Aurora reaches the top of the band, around 66%. The provisioned tier of a Database Savings Plan tops out around 20%, on a 1-year No Upfront term. That’s a deliberately deepest-against-shallowest comparison — the 3-year all-upfront RI is the deepest commitment AWS sells, and the plan has no 3-year or upfront tier to match it. That’s not a rounding difference — it’s the price of the flexibility. You’re trading somewhere around 30 to 45 points of discount for the freedom to change engine, family, and region without penalty.

So the decision rule we’d use:

Predictable, unchanging, long-lived fleet you’re confident about for 3 years → the 3-year all-upfront RI’s deeper discount likely wins, if you can honestly promise not to touch it.
Anything you might right-size, migrate, modernize, or move regions → the Database Savings Plan, every time. The flexibility is worth more than the extra discount points the moment you’d otherwise forfeit them.
Realistically, most fleets → a base layer of RIs on the truly static core, topped by a Database Savings Plan for everything that flexes. They layer rather than compound: the RI applies first to its matched instance-hours, and the Savings Plan then discounts whatever’s left at on-demand.

The trap is over-estimating how “frozen” your fleet really is. Teams talk themselves into a 3-year RI to bank the deeper rate, then spend two years unable to modernize without lighting money on fire. If you’re not certain — and the Graviton generation cadence alone (r7g, r8g, and whatever’s next) makes “certain” a strong claim — the flexible plan usually costs less over the real life of the workload.

The bigger pattern

The through-line here is one we keep hitting on AWS: the discount should follow good engineering, not fight it. Compute Savings Plans did this for EC2 and Lambda years ago — commit to spend, let it float across families and regions. Database Savings Plans finally extend that model to the data tier, which is exactly where rigidity hurt most, because databases are the hardest thing to migrate and the most expensive to get wrong.

If you’re weighing this against an RI renewal, the move is to model both against your actual modernization roadmap — including the Graviton upgrades and engine migrations you’ve been deferring. That’s the same lens we bring to a cost review: not just “what’s the cheapest rate today,” but “what commitment lets you keep improving the architecture without a penalty.” We saw the same principle pay off pairing Graviton with our Kyte framework for a 64% cost reduction, and in the EC2 Graviton migration that preceded it.

If your database spend has crept past where it should be and you’d rather not model RI-versus-Savings-Plan scenarios across every eligible service yourself, that’s the kind of cost review we do — the first pass usually finds enough to cover the engagement.

Sources / last verified 2026-07-20: AWS News Blog, Introducing Database Savings Plans for AWS Databases (Dec 2, 2025) and the Database Savings Plans pricing page — discount tiers (up to 35% serverless / 20% provisioned / 18% DynamoDB-Keyspaces on-demand / 12% DynamoDB-Keyspaces provisioned), 1-year No Upfront term, current-generation and ElastiCache-Valkey eligibility, cross-engine/family/region flexibility, migration examples; AWS, Database Savings Plans now support Amazon OpenSearch Service and Amazon Neptune Analytics (Mar 5, 2026) — expanded coverage; AWS, Amazon RDS Reserved Instances and Amazon Aurora pricing — 3-year all-upfront RI depth by engine (db.r8g, Graviton4); ProsperOps, AWS Database Savings Plans – Everything You Need to Know (Feb 2026, updated Mar 2026) — the service-specific-PPA crowd-out analysis and the ~~$30K→~~$21.5K worked example.