Database Savings Plans vs Reserved Instances: what to buy

TL;DR. A Database Savings Plan is a 1-year, no upfront commitment in dollars per hour. In the US East rate file it takes 20% off every Generation 7 and newer RDS and Aurora instance it lists, 35% off Aurora Serverless v2 and 18% off DynamoDB on-demand. A 1-year no upfront Reserved Instance takes 23% off db.r7g, 33% off db.r8g and about 42% off db.r6g, which the plan does not cover at all. On a seven-database fleet, Reserved Instances on the steady db.r8g pair plus a plan on everything else cost $25,106.54 a year, 27.7% under on-demand, against 21.5% for the plan alone.

Database Savings Plans and Reserved Instances solve different problems, and the instance generation decides how much the plan's flexibility costs you. On db.r7g it costs 3 points of discount. On db.r8g it costs 13. This post prices both from AWS's own rate files, runs one fleet through three strategies, and shows how to size the commitment so that it does not bill for databases you no longer run.

Database Savings Plans vs Reserved Instances: the gap depends on the instance generation

AWS describes the plan as "a flexible pricing model that reduces your database costs by up to 35%" in exchange for a 1-year commitment. The 35% is the Aurora Serverless v2 rate. For provisioned instances, every rate in the US East rate file is 20% below on-demand. Reserved Instance discounts, read from the RDS price list, vary by generation:

All-upfront rates are amortized over 8,760 hours. On db.r7g and db.m7g, the plan gives up about 3 points to a Reserved Instance. On db.r8g and db.m8g it gives up 13. ProsperOps lists the same split by family: 23% for 7g and 33% for 8g reservations against the plan's 20%. What its table leaves out is Generation 6.

The older generations are the counter-intuitive row. AWS says the plan covers "Generation 7 and newer instances", and no db.r6g, db.r6i or db.r5 rate appears in the file. Their Reserved Instances are the deepest 1-year discounts in the table: a db.r6g.large RI costs 32.1% less per hour than a db.r8g.large on the plan. Moving a db.r6g to db.r8g to become plan-eligible raises the hourly rate unless the newer instance lets you run a smaller size.

What each one covers, and where the plan is the only commitment

The plan is broader than any reservation. AWS lists Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS and OpenSearch Service, and the commitment follows usage "regardless of supported engine, instance family, size, deployment option, or AWS Region". A Reserved Instance is size-flexible only within its instance class type: a db.r7g reservation does not cover a db.r8g.

Three rows decide most purchases. Aurora Serverless v2 and DynamoDB on-demand have no reservation, so the plan is the only discount they can get: $0.078 instead of $0.12 per ACU-hour, and $0.1025 instead of $0.125 per million read request units. DynamoDB provisioned capacity is the opposite: the DynamoDB price list prices 1-year reserved write capacity at a $1.50 upfront fee plus $0.000128 per hour per unit, an effective $0.000299 an hour against $0.00065 on-demand, 54% off. The plan takes 12%. And the Savings Plans FAQ lets you return a plan "that has an hourly commitment of $100 or less, purchased in the past 7 days and in the same calendar month"; a reservation has no such window.

Both commitments discount compute and throughput only. Storage, I/O, backups and transfer stay at list price, which is why the plan cut the whole bill by only 8.8% in our RDS pricing example. On RDS for SQL Server, the plan discounts the instance price only and "licensing charges are billed separately at on-demand rates".

One fleet, priced three ways: Reserved Instances where steady, the plan for the rest

Consider a hypothetical team on US East with seven databases, all running every hour of the year:

• 2 RDS for PostgreSQL db.r8g.xlarge, Multi-AZ, the production pair nobody plans to touch.
• 2 RDS for PostgreSQL db.m7g.large, Single-AZ, internal apps.
• 1 Aurora PostgreSQL cluster of 2 db.r7g.large.
• 1 Aurora PostgreSQL Serverless v2 cluster averaging 4 ACU.
• 1 DynamoDB on-demand table with 2 billion read and 400 million write request units a month ($250 each at list price).

Annual cost of compute and requests, at the rates above (Multi-AZ db.r8g.xlarge: $0.956 on-demand, $0.7648 plan, $0.6410 RI):

Reserved Instances alone and the plan alone land about $160 apart, for opposite reasons. The RIs win on the db.r8g pair and leave serverless and DynamoDB at full price; the plan covers those and loses 13 points on the db.r8g pair. The split takes the best of each.

Putting Reserved Instances on the db.m7g and Aurora db.r7g lines too would save another $222.50 a year. That is the whole price of keeping four databases flexible: if the internal apps move to Aurora Serverless or the cluster moves to db.r8g, the plan follows them; a db.m7g reservation keeps billing for instances that no longer exist.

For a pair you will keep three years, the 3-year no upfront db.r8g.xlarge Multi-AZ reservation is $0.4493 an hour, 53.0% off, or $7,871.74 a year for both.

How much to commit: the hourly floor, after the cleanup

The plan bills its commitment every hour. AWS's own example states that "each hour's commitment can only be used within that hour and cannot be carried over". If eligible usage in an hour is worth less than the commitment at plan rates, you pay for the difference anyway.

That sets a break-even. A commitment of C dollars an hour buys C / (1 - d) of on-demand usage at discount d. You only beat on-demand while that hour's usage fills more than 1 - d of it: 80% for instances, 65% for Serverless v2, 82% for DynamoDB on-demand.

Order matters too. AWS applies a plan "to your highest savings percentage first", so in a mixed fleet the first dollars go to Serverless v2 at 35%. Serverless capacity is the line that moves most from hour to hour, so measure the floor on the whole eligible fleet, hour by hour, never on a monthly average.

1. Retire before you measure. Suppose the team in our example buys the plan-only commitment, $3.1136 an hour, then deletes the two db.m7g.large four months later. The commitment keeps billing $196.22 a month for them: $1,569.79 over the remaining eight months, against $1,514.90 for a reservation. The plan protects you from moving a database, and does not protect you from removing one.
2. Find the hourly floor. In an hourly CUR 2.0 export, sum the on-demand cost of plan-eligible lines per hour and scale each by its plan rate. Rows already under a reservation are typed DiscountedUsage and rows under a plan SavingsPlanCoveredUsage, so filtering on Usage keeps only uncovered usage. The factors are the US East ratios from this post; check yours in the rate file. The rate file has no plan rate for Oracle or Db2 bring-your-own-license instances or for RDS on Outposts, so filter those out if you run them.

WITH hourly AS (
  SELECT line_item_usage_start_date AS hour,
         sum(line_item_unblended_cost * CASE
           WHEN regexp_like(line_item_usage_type, 'ServerlessV2') THEN 0.65
           WHEN regexp_like(line_item_usage_type, 'RequestUnits') THEN 0.82
           ELSE 0.80 END) AS plan_dollars
  FROM cur2
  WHERE line_item_line_item_type = 'Usage'
    AND line_item_product_code IN ('AmazonRDS', 'AmazonDynamoDB')
    AND (regexp_like(line_item_usage_type, '(InstanceUsage|Multi-AZUsage)[A-Za-z]*:db\.[a-z]+[789]')
         OR regexp_like(line_item_usage_type, 'ServerlessV2|ReadRequestUnits|WriteRequestUnits'))
  GROUP BY 1
)
SELECT min(plan_dollars) AS floor,
       approx_percentile(plan_dollars, 0.05) AS p5
FROM hourly;

3. Subtract what new reservations will cover, then commit at or just under the floor. AWS's Savings Plans recommendations project the same thing from your history, including usage that stays on-demand "due to hour-to-hour variations"; they cannot know which databases you are about to delete.

In the recommended split above, the commitment is $1.5840 an hour for the plan's four lines, about half the plan-only $3.1136.

The fair objection: the 3 points a plan gives up on db.r7g are small, and one commitment is simpler to manage than a stack of reservations. For a fleet still on db.r7g and db.m7g, that is a good argument for the plan alone. It weakens as instances move to the 8g classes, where each reservation is worth 13 points, and it does not apply to Generation 6 fleets, which the plan cannot cover.

Limits: US East list prices on November 8, 2026, PostgreSQL only, no Enterprise Discount Program or private pricing. The fleet is hypothetical and assumes steady usage every hour. The SQL is a sketch that has not been run against a real export, and the factors change with each rate file. Google Cloud and Azure sell their own commitments; our cloud database cost comparison prices one Postgres on all three.

A commitment locks in today's usage for a year, so the input that matters is which databases are used, by whom, and what each costs. Datapace is building one map of your data estate (databases, warehouses, pipelines and what consumes them) with usage and cost attached, and agents that propose changes as pull requests your team reviews and merges. Before you commit, find the databases to retire with the per-instance method in our RDS cost optimization guide.

Sources

1. AWS, Database Savings Plans pricing and Savings Plans FAQ, read November 8, 2026.
2. AWS Price List API, Database Savings Plans rate file, US East, published November 3, 2026, read November 8, 2026.
3. AWS Price List API, Amazon RDS offer, US East, published October 29, 2026, read November 8, 2026 (on-demand and Reserved Instance rates).
4. AWS Price List API, Amazon DynamoDB offer, US East, published November 5, 2026, read November 8, 2026 (on-demand and reserved capacity rates).
5. AWS docs, How Savings Plans apply to your usage and Understanding Savings Plans recommendations.
6. AWS docs, Data dictionary for CUR 2.0 line item columns.
7. AWS docs, Reserved DB instances for Amazon RDS.
8. AWS, Amazon DynamoDB pricing for provisioned capacity.
9. ProsperOps, AWS Database Savings Plans: everything you need to know.