Cost

Reserve Azure Database for PostgreSQL capacity

One cost lever for steady-state databases: prepay the compute you already run for a one or three year term, and stop paying the pay-as-you-go rate on capacity that never switches off.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Reserving PostgreSQL capacity: the basics

What is Azure Advisor actually telling you to buy?

Azure Advisor raises a cost recommendation, 'Consider Database for PostgreSQL reserved instance to save over the pay-as-you-go costs', when it sees a flexible server running steadily enough that prepaying its compute would cost less than paying by the hour. A reserved capacity purchase is a commitment: you tell Azure you will run a given amount of PostgreSQL compute, in a given region and performance tier, for one or three years, and in return the compute charges that match drop from the pay-as-you-go rate to the reserved rate. Microsoft documents savings of up to 65 per cent on compute against pay-as-you-go for these reservations.

The recommendation is not asking you to change anything about the database. There is no migration, no downtime, no new resource attached to the server. A reservation is a billing instrument. An already-running flexible server, or one you deploy tomorrow, automatically receives the discount as soon as its attributes match an active reservation. You do not assign a reservation to a specific server; Azure applies the benefit to whatever qualifying compute is running in the chosen scope.

The one thing to get right is sizing. A reservation covers compute only, the vCores, not the storage, backup, networking or software charges on the server. It is bought for a specific region, deployment type and performance tier, so the question is not 'should we reserve PostgreSQL?' in the abstract, it is 'how many vCores of this exact shape do we run around the clock, every month, that we are confident will still be running in a year?' Reserve that floor, and leave the variable part on pay-as-you-go.

In this lesson you will learn what the Azure Advisor reserved-capacity recommendation for Azure Database for PostgreSQL is really proposing, how reserved pricing applies to a flexible server without touching the database, how to size a reservation so the discount lands on real steady-state compute, and how to buy and verify one from the portal, the az CLI or Bicep. The aim is a reservation that captures the saving Advisor identified without over-committing.

Fun fact

The discount hiding in the hourly rate

Pay-as-you-go pricing is, in effect, a flexibility premium: the hourly rate bundles in the option to switch a resource off at any moment and stop paying. For a database that never switches off, that option is worthless, yet you pay for it every hour. Reserved capacity simply lets you hand the option back in exchange for a lower rate. It is the same compute, the same server, the same performance; the only thing that changes is the line on the invoice. Azure even applies the benefit automatically to matching servers you have not deployed yet, so a reservation bought today quietly discounts the production server you stand up next month.

Finding the reservable floor across a subscription

Priya runs the platform team at a scale-up whose Azure bill is climbing as the product grows. Advisor has surfaced the 'Consider Database for PostgreSQL reserved instance' recommendation against the production estate, and the instinct is to click buy. Priya wants to size it properly first.

Advisor builds the recommendation by analysing hourly usage over a lookback window, defaulting to 30 days, and recommending the quantity that would have maximised savings. Before committing, Priya lists the flexible servers and their compute shapes, so the steady production servers can be told apart from the dev and test servers that should stay on pay-as-you-go.

List the flexible servers with their tier and vCore count, so you can see which shapes are running steadily and worth reserving.

$ az postgres flexible-server list --query "[].{name:name, region:location, tier:sku.tier, vcores:sku.name}" -o table

Name Region Tier Vcores

---------------- -------- --------------- -----------------

orders-prod uksouth GeneralPurpose Standard_D4ds_v5

billing-prod uksouth GeneralPurpose Standard_D4ds_v5

analytics-dev uksouth GeneralPurpose Standard_D2ds_v5

# Two steady prod servers share a shape in uksouth: reserve that floor. Leave the dev server on demand.

Two production servers of the same tier in the same region are the reservable floor. The dev server scales down out of hours, so it stays on pay-as-you-go.

How a PostgreSQL reservation actually appliesdeep dive

A reservation is a billing object, not a property of the server. When you buy one you specify a region, a deployment type, a performance tier and a quantity of vCores, plus a term of one or three years and a scope. Azure then matches that reservation, hour by hour, against the qualifying PostgreSQL compute running in scope and applies the reserved rate to whatever matches, up to the reserved quantity. Compute beyond the reserved quantity, or compute that does not match the attributes, continues to bill at the pay-as-you-go rate. The reservation covers compute only: storage, backup, networking and software charges on the server are billed normally regardless.

Because the benefit is matched rather than attached, vCore size flexibility lets you scale up or down within the same performance tier and region without losing it. If you scale a reserved server to a larger size, the reservation still discounts up to the vCores you reserved and the excess bills on demand; if you scale down, the freed reserved capacity flows to other matching servers in scope. The scope itself can be a single subscription, a single resource group, a management group, or shared across all subscriptions in the billing account, which determines how widely the discount roams to find matching compute.

Advisor decides a server is a candidate by analysing hourly usage over a lookback window, 7, 30 or 60 days with 30 as the default, computing what a reservation would have cost against the actual pay-as-you-go spend, and recommending the quantity that would have maximised the saving. Because it is usage-driven, the recommendation only fires once a server has run long enough to establish a steady pattern, which is exactly the signal that the compute is safe to commit. Reservations do not auto-renew unless you opt in, and you receive an expiry notice 30 days out, after which unmatched compute simply returns to the pay-as-you-go rate.

What is the impact of leaving steady compute on pay-as-you-go?

The direct impact is straightforward overspend. Every hour a steady-state production database runs on the pay-as-you-go rate when it could be running on a reserved rate is the discount, up to 65 per cent on the matching compute against pay-as-you-go, left unclaimed. For a server that runs continuously, that gap compounds across thousands of hours a year, and it recurs for as long as the workload exists and the reservation does not.

The second-order impact is that the most predictable spend in the estate, the part most amenable to a clean financial commitment, is the part being managed least deliberately. Pay-as-you-go is the right default for genuinely variable workloads, but using it for a database that never switches off is paying a flexibility premium for flexibility the workload does not need. Leaving the recommendation unactioned is not neutral; it is an ongoing decision to pay more for the same compute.

There is also a forecasting cost. Reserved capacity converts a variable hourly charge into a known commitment, which makes the database line of the cloud budget predictable for the term. An estate that reserves its steady floor can forecast that floor with confidence; an estate that runs everything on demand carries avoidable variance in the most stable part of its bill. The trade is not risk for saving, it is flexibility you are not using for a lower, more predictable rate.

How do you capture the saving safely?

Treat this as a sizing exercise, not a purchase. The order matters: confirm the steady floor before you commit, so you reserve compute you are confident will still be running for the term, and leave the variable layer alone.

1. Separate the steady floor from the variable layer

List your flexible servers by region, deployment type, performance tier and vCore count. The reservable floor is the production compute that runs continuously at a stable shape; the variable layer is the dev, test and burst capacity that scales down or gets torn down. Only the floor should be reserved.

2. Size against real usage, not the headline

Advisor sizes its recommendation on hourly usage over a lookback window. Confirm the proposed quantity against the steady floor you actually identified, rather than accepting a number that may lean on variable servers. Reserve the vCores you are confident will run for the whole term, and leave the rest on pay-as-you-go.

3. Choose term, scope and billing deliberately

Pick one year for a near-certain payback or three years where the workload horizon supports a deeper discount. Choose a scope, single subscription, single resource group, management group or shared, wide enough for the benefit to find your matching servers. Choose upfront or monthly billing to suit cash flow; the discount is the same either way.

4. Buy, verify and set a review date

Price the reservation with the calculate command before purchasing, buy it, then confirm matching servers are receiving the benefit in Cost Management. Reservations do not auto-renew unless you opt in, so note the expiry. If the fleet shifts, use self-service exchange or refund to reshape the commitment rather than letting it drift.

# 1. Preview the price and saving BEFORE committing. Confirm the sku/tier/region
#    match the steady servers you identified, and that the quantity is your floor.
billingScope="/subscriptions/00000000-0000-0000-0000-000000000000"

az reservations reservation-order calculate \
  --reserved-resource-type PostgreSql \
  --sku Standard_D4ds_v5 \
  --location uksouth \
  --term P1Y \
  --billing-plan Upfront \
  --applied-scope-type Single \
  --applied-scope "$billingScope" \
  --billing-scope "$billingScope" \
  --quantity 2 \
  --display-name pg-prod-uksouth-1yr

# 2. The calculate response returns a reservationOrderId. Purchase against it.
az reservations reservation-order purchase \
  --reservation-order-id <reservationOrderId-from-calculate> \
  --reserved-resource-type PostgreSql \
  --sku Standard_D4ds_v5 \
  --location uksouth \
  --term P1Y \
  --billing-plan Upfront \
  --applied-scope-type Single \
  --applied-scope "$billingScope" \
  --billing-scope "$billingScope" \
  --quantity 2 \
  --display-name pg-prod-uksouth-1yr

Quick quiz

Question 1 of 5

Azure Advisor raises 'Consider Database for PostgreSQL reserved instance to save over the pay-as-you-go costs' against a production server. What is it actually proposing?

Keep learning

Go deeper on how reserved capacity prices Azure Database for PostgreSQL and how Azure sizes and applies the benefit.

You can now read the Azure Advisor reserved-capacity recommendation for what it is: an offer to reprice compute you already run, at up to 65 per cent off against pay-as-you-go, with no change to the database. Separate the steady production floor from the variable layer, size the reservation to the floor, preview the price with the calculate command, choose term, scope and billing deliberately, then verify the benefit lands and set a review against expiry.

Back to the library

Reserving PostgreSQL capacity: the savings view

A discount you buy on compute you are already paying full price for

This is the rare Advisor recommendation that lowers the bill rather than protecting against a risk. The flexible server is already running and already being paid for at the pay-as-you-go rate. A reservation does not add a workload or a feature; it re-prices compute you have committed to running anyway, at up to 65 per cent off against pay-as-you-go for the matching vCores. The saving is the spread between the on-demand rate and the reserved rate, multiplied by the hours the server runs, over the term.

The decision is a commitment, so it is finance's to frame, not the platform team's. The right question is how much of the database fleet is genuinely steady-state: production servers that run at the same shape month after month, not the dev and test servers that scale down at night or get torn down between sprints. Reserve the steady floor and the saving is close to guaranteed; over-reserve a shape you later resize away from and you have prepaid for capacity the discount no longer fully matches.

The payback is straightforward to model. An upfront one-year reservation pays for itself within the term by definition once the server runs the hours Advisor based the recommendation on; the three-year term deepens the discount further if the workload horizon supports it. And the commitment is not a trap: Azure allows self-service exchange and refund, so a reservation can be unwound or reshaped if the fleet changes.

This lesson is for the finance partner who sees the reserved-instance recommendation on the cost report and wants to know what it saves, what it commits to, and how to judge whether the workload is steady enough to justify locking in a one or three year rate. It covers the payback model, the difference between the reservable floor and the variable layer, and the exchange and refund safety net.

Fun fact

The discount hiding in the hourly rate

How a finance partner sizes the commitment

Priya is the finance partner reviewing the cost report when the reserved-instance recommendation lands with an estimated annual saving attached. The instinct is not to approve the headline number; it is to ask what is actually steady. The platform team confirms two production servers, orders-prod and billing-prod, run the same General Purpose shape in UK South around the clock and have done for months, while analytics-dev scales to almost nothing overnight. Advisor sized the recommendation on 30 days of hourly usage and proposed the quantity that maximised savings, but that figure can lean on the variable servers too, so Priya reserves only the production floor.

The sum is the part finance owns. The two production servers represent a fixed block of vCores running every hour; the saving is the spread between the pay-as-you-go rate and the reserved rate on that block, which Microsoft documents at up to 65 per cent against pay-as-you-go for the matching compute. Priya models both terms: a one-year upfront reservation that pays back within the year by definition, and a three-year term that deepens the discount if the product roadmap supports a three-year horizon for these services. The dev server stays on demand because its saving would be illusory, prepaid hours it never runs. The pack reads: 'Reserve the production floor at the one-year rate for a near-certain saving; revisit the three-year term once the roadmap is firm; leave dev and test on pay-as-you-go.'

Why the reservation belongs on the savings register

The cost model here is unusually clean. The compute is already running and already being paid for at the pay-as-you-go rate, so the reservation does not create a new cost, it reprices an existing one downward. The saving is the spread between the on-demand and reserved rates on the steady block of vCores, and it is close to certain for compute that genuinely runs around the clock, because Advisor only recommends it after observing a sustained usage pattern.

The discipline finance brings is separating the reservable floor from the variable layer. The saving on a production server that runs continuously is real; the apparent saving on a dev server that scales down overnight is partly fictional, because a reservation prepays for hours the server never runs. Reserve the floor, model the one-year term for the near-certain payback and the three-year term where the workload horizon supports it, and treat the exchange and refund route as the safety net that keeps the commitment from becoming a trap.

What finance can do about the saving

Finance cannot buy the reservation, but it owns the framing that turns a headline saving into a sized, justified commitment with a clear payback and a safety net. Three levers.

1. Insist the commitment is sized to the steady floor

Make explicit that a reservation only saves money on compute that actually runs for the term. Ask the team to separate the production servers that run continuously from the dev, test and burst capacity that scales down, and reserve only the former. A reservation sized to the floor delivers a near-certain saving; one sized to the Advisor headline can prepay for variable hours that never materialise.

2. Model both terms and pick on horizon, not on discount alone

The three-year term carries a deeper discount, but it is only the better deal if the workload genuinely lives three years at that shape. Model the one-year payback, which is near-certain for steady compute, against the three-year saving weighted by how confident the roadmap is. Commit the floor at one year now if the horizon is uncertain, and extend to three years for the services you are sure will persist.

3. Treat exchange and refund as the governing safety net

The reason a reservation is not a trap is that Azure allows self-service exchange and refund. Record that explicitly so the commitment reads as reversible, not as a one-way door. If the fleet resizes or a service is retired, the reservation can be reshaped or unwound, which means the downside of committing the floor is bounded while the saving is recurring.

Quick quiz

Question 1 of 5

Advisor shows an estimated annual saving on the reserved-instance recommendation. As the finance partner, what is the right first move?

Keep learning

Go deeper on how reserved capacity prices Azure Database for PostgreSQL and how Azure sizes and applies the benefit.

You have finished the finance view of reserving PostgreSQL capacity. You know the saving is the spread between the pay-as-you-go and reserved rates on genuinely steady compute, that the one-year term pays back near-certainly while the three-year term trades a deeper discount against roadmap confidence, and that self-service exchange and refund keep the commitment reversible. Next time the recommendation lands, you will size it to the floor, model both terms, and put the realised saving and utilisation on the review rather than just the spend.

Back to the library

Reserving PostgreSQL capacity: the headline

Whether the estate pays list price for compute it runs every hour of every day

Some cloud spend is genuinely variable and should stay on pay-as-you-go, where you only pay for what you burst to. Steady-state databases are the opposite: a production PostgreSQL server runs the same shape every hour of every day, and paying the on-demand rate for it is paying a premium for flexibility you are not using. A reservation converts that predictable floor to a committed rate, at up to 65 per cent off compute against pay-as-you-go.

The leadership question is not technical. It is 'how much of our database compute is predictable enough to commit, and are we capturing the discount that predictability earns?' An estate that runs everything on pay-as-you-go is leaving money on the table; an estate that reserves recklessly locks itself into shapes it may outgrow. The defensible position is in between: reserve the steady production floor, keep the variable layer on demand, and revisit as the fleet moves.

This is a return-on-investment decision, not a risk one. The downside of acting is small and bounded, because reservations can be exchanged or refunded. The downside of never acting is paying full price, indefinitely, for the most predictable spend in the estate.

A short read for the leader who needs to understand why predictable database compute should not be paid for at on-demand rates, what a reservation commits the business to, and what a sensible reserve-the-floor posture looks like across the estate.

Fun fact

The discount hiding in the hourly rate

What it looks like when predictable spend is actually committed

At a cost review, the CFO noticed the Azure bill rising in step with revenue and asked the obvious question: is any of this spend predictable enough that we should be getting a discount on it? The honest answer at the time was that the production databases ran at full pay-as-you-go rates because nobody had taken the reservation decision, even though those servers had run the same shape for the better part of a year.

The team's response was to separate the estate into a committed floor and a variable layer. They identified the production PostgreSQL servers that run continuously at a stable shape, reserved that compute for a one-year term, and left the dev, test and burst capacity on pay-as-you-go where the flexibility is worth paying for. The next review told a different story: the predictable spend was now booked at the reserved rate, the saving was a line item the CFO could see, and the commitment was bounded because reservations can be exchanged or refunded if the fleet changes. The shift, from paying list price for everything to paying the committed rate for the predictable part, is the return this recommendation delivers, and it requires no change to the databases themselves.

Why this is a board-level efficiency question

The most predictable spend in a cloud estate is also the easiest to optimise, and steady-state databases are about as predictable as cloud spend gets. Paying the on-demand rate for a server that runs every hour of every day is paying a premium for flexibility the workload will never use. Capturing the reserved rate on that compute is a pure efficiency gain, with no change to the service and no operational risk.

The cost of getting this right is small and bounded, because reservations can be exchanged or refunded if the fleet changes. The cost of never addressing it is paying list price indefinitely for the steadiest part of the bill. This is the rare class of decision where the upside is recurring and the downside is capped, which is exactly the trade leadership should be quickest to approve, provided the commitment is sized to genuinely steady compute.

The leadership move on reserved capacity

The executive handle is not to approve individual purchases; it is to require that predictable database compute is committed rather than paid for at list price, and that the commitment is sized to genuinely steady workloads and reviewed as the fleet moves.

1. Require a reserve-the-floor posture, not all-or-nothing

Set the expectation that steady-state production compute is reserved and variable compute stays on pay-as-you-go. The goal is not to reserve everything, which over-commits, nor to reserve nothing, which overpays. It is to capture the discount on the predictable floor and keep flexibility where the workload genuinely needs it.

2. Ask for the saving and the payback, not just the spend

The proof that this is working is not 'we bought a reservation.' It is a visible saving line against the prior pay-as-you-go rate, a stated payback period, and a quantity that maps to identified steady servers. Ask for the reservation utilisation report so you can see the committed capacity is actually being matched by running compute.

3. Set a review cadence tied to expiry and fleet change

Reservations do not auto-renew unless opted in, and fleets move. Ask for a standing review before each reservation expires and whenever the database estate is resized, using exchange and refund to keep the commitment aligned with what is actually running. A reservation that is bought once and forgotten can drift into prepaying for compute the estate no longer runs.

Quick quiz

Question 1 of 5

At a cost review you ask whether the estate captures the discount its predictable spend earns. What end state should you be looking for?

Keep learning

Go deeper on how reserved capacity prices Azure Database for PostgreSQL and how Azure sizes and applies the benefit.

Two takeaways. Predictable database compute should not be paid for at list price: reserving the steady floor is a recurring efficiency gain with a bounded downside, which makes it a trade to approve quickly. And the right posture is reserve-the-floor, not all-or-nothing: commit the steady production compute, keep the variable layer flexible, and review before each reservation expires so the commitment stays aligned with what the estate actually runs.

Back to the library

Part of the learning path Lock in Azure commitments

Reserve Azure Database for PostgreSQL capacity

Reserving PostgreSQL capacity: the basics

The discount hiding in the hourly rate

Finding the reservable floor across a subscription

How a PostgreSQL reservation actually appliesdeep dive

What is the impact of leaving steady compute on pay-as-you-go?

How do you capture the saving safely?

1. Separate the steady floor from the variable layer

2. Size against real usage, not the headline

3. Choose term, scope and billing deliberately

4. Buy, verify and set a review date

Quick quiz

Keep learning

Reserving PostgreSQL capacity: the savings view

The discount hiding in the hourly rate

How a finance partner sizes the commitment

Why the reservation belongs on the savings register

What finance can do about the saving

1. Insist the commitment is sized to the steady floor

2. Model both terms and pick on horizon, not on discount alone

3. Treat exchange and refund as the governing safety net

Quick quiz

Keep learning

Reserving PostgreSQL capacity: the headline

The discount hiding in the hourly rate

What it looks like when predictable spend is actually committed

Why this is a board-level efficiency question

The leadership move on reserved capacity

1. Require a reserve-the-floor posture, not all-or-nothing

2. Ask for the saving and the payback, not just the spend

3. Set a review cadence tied to expiry and fleet change

Quick quiz

Keep learning

Related cost lessons