Cost

Right-size underutilised Azure Database for PostgreSQL servers

One capability for the managed database bill: find every Azure Database for PostgreSQL flexible server that has sat underutilised for weeks, and drop its compute tier or vCore count to the size the workload actually needs, so you stop paying for cores that never run.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Right-sizing PostgreSQL flexible servers: the basics

What does an oversized Azure Database for PostgreSQL server actually look like?

An Azure Database for PostgreSQL flexible server is billed first and foremost on its compute, and compute is the vCore count and tier you picked when the server was created. The price is fixed by the size, not by how busy the database is. A server provisioned with eight vCores in the General Purpose tier costs the same whether it is running flat out or sitting at four per cent CPU all month. When a server is consistently idle, the gap between the size you are paying for and the size the workload needs is pure waste on the bill, and it recurs every single hour until someone changes the SKU.

Azure Advisor turns this into a cost recommendation. Advisor watches the server's utilisation telemetry and, when a server has been underutilised for an extended period, it raises a right-sizing recommendation. For the sibling MySQL engine the recommendation reads, verbatim: 'Our internal telemetry shows that the MySQL database server resources have been underutilized for an extended period of time over the last 7 days. Low resource utilization results in unwanted expenditure which can be fixed without significant performance impact. To reduce your costs and efficiently manage your resources, we recommend reducing the compute size (vCores) by half.' The same right-sizing engine Advisor applies across MariaDB, MySQL and PostgreSQL produces the equivalent recommendation for a PostgreSQL flexible server: halve the vCores, or move down a tier, and keep the same workload.

Most of this overprovisioning is history, not need. A server sized for a launch that never reached the traffic that was forecast. A production SKU copied into a dev or staging environment that only sees a developer twice a week. A General Purpose server doing the job a Burstable one would do for a fraction of the price. The work is to find every flexible server whose CPU and memory have stayed low for weeks, confirm the low utilisation is steady-state rather than a quiet window before a known peak, and scale it to the size the workload actually uses.

In this lesson you will learn how an Azure Database for PostgreSQL flexible server is priced, how Azure Advisor decides a server is underutilised and worth right-sizing, how to confirm the low utilisation is genuine before you scale, and how to drop a server's tier or vCores safely with the az CLI or Bicep. The aim is a repeatable loop that turns Advisor's right-sizing recommendations into recurring savings on the database bill.

Fun fact

The half that nobody noticed

Azure Advisor's right-sizing recommendation for the managed database engines does not hedge: its standard remedy is to reduce the compute size by half. That tells you something about how common steady-state idle databases are. The recommendation engine has seen enough servers running at a fraction of their provisioned compute, week after week, that halving is the default first move rather than a cautious nudge. The compute was paid for in full the whole time, and in many estates the recommendation sits dismissed or unread, so the bill keeps charging for the half that nobody is using.

Finding underutilised PostgreSQL servers across a subscription

Priya runs the platform team at a scale-up whose Azure bill has crept up as the estate grew. Azure Advisor's Cost tab shows several right-sizing recommendations against Azure Database for PostgreSQL flexible servers that were provisioned generously during a growth push that never fully materialised.

Rather than scale them blind, Priya pulls the right-sizing recommendations from Advisor and then checks each flagged server's actual CPU and memory over the past weeks, so a genuinely idle server can be told apart from one that only looks quiet between known peaks.

Start by listing the Advisor cost recommendations that target PostgreSQL flexible servers. These are the servers Advisor has judged underutilised over a sustained window.

$ az advisor recommendation list --category Cost \ --query "[?contains(impactedField, 'flexibleServers')].{server:impactedValue, problem:shortDescription.problem}" -o table

Server Problem

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

orders-pg-staging Right-size underutilized database server

reporting-pg-prod Right-size underutilized database server

# Now confirm utilisation per server before scaling. Idle staging = risk-free cut.

Advisor only flags servers underutilised over a sustained window, but confirm CPU and memory yourself before scaling, so you do not catch a server in a trough before a known peak.

How Azure Advisor decides a flexible server is underutiliseddeep dive

Advisor's right-sizing recommendation rests on the server's utilisation metrics in Azure Monitor. For an Azure Database for PostgreSQL flexible server the key signals are 'cpu_percent' and 'memory_percent' in the 'Microsoft.DBforPostgreSQL/flexibleServers' namespace, each emitted at a one-minute interval. Advisor analyses these over a sustained look-back window, an extended period over roughly the last seven days for the equivalent managed-database recommendation, and when utilisation stays low throughout, it concludes the provisioned compute is larger than the workload needs and raises the recommendation, typically suggesting the vCores be reduced by half.

Compute is what you are paying to reduce. A flexible server's compute is a tier ('Burstable', 'GeneralPurpose' or 'MemoryOptimized') and an SKU within it (for example 'Standard_B1ms', 'Standard_D2s_v3' or 'Standard_D4s_v3'), and the compute charge is fixed by that choice regardless of how busy the database is. Right-sizing means moving to a smaller SKU in the same tier, or moving down a tier entirely, for instance from General Purpose to Burstable for a workload that does not need continuous full capacity. Storage is billed separately and is not what this recommendation is about.

Two mechanics shape how you act on the recommendation. First, scaling compute requires a server restart, so the change is applied during a brief window of unavailability rather than instantly and silently. Second, PostgreSQL flexible server does not support in-place vertical scaling from the Burstable tier up to the other tiers, so a server you move down to Burstable is a deliberate choice you should be confident about, because moving it back up is not a simple in-place operation. Neither mechanic blocks the saving; they just mean you schedule the restart and you are sure about a move to Burstable.

What is the impact of leaving servers oversized?

The direct impact is recurring waste. An oversized flexible server charges its full compute rate every hour it runs, whether or not the workload uses the cores, so the gap between the SKU you pay for and the SKU the workload needs is money leaving the account on a continuous basis. Advisor's standard remedy of halving the vCores hints at the scale of it: where the recommendation applies, roughly half the compute spend on that server has been buying capacity that sat idle.

The second-order impact is drift that compounds. One oversized server is a rounding error; an estate where provisioning-time guesses are never revisited is a structural overspend that grows with every new service. Each server that is sized once and forgotten adds a permanent line to the bill, and because managed-database spend looks stable and predictable, the waste hides in plain sight. Right-sizing as a routine keeps the bill tracking actual usage instead of accumulating the high-water mark of every past forecast.

On the upside, the saving is durable and free to capture. Unlike a discount that has to be purchased or a commitment that has to be negotiated, right-sizing an idle server costs nothing and the lower rate persists for the life of the workload. It also stacks: a server right-sized to the SKU it actually needs is then a smaller, cheaper base to apply a reserved-capacity commitment to, where Microsoft documents reserved pricing for PostgreSQL flexible server of up to 40 per cent for a one-year and up to 60 per cent for a three-year commitment. Right-size first, then reserve, so you are not committing to capacity you do not use.

How do you right-size a flexible server safely?

Work the capability as one loop rather than reacting to each recommendation in isolation. The order matters: confirm the low utilisation is genuine before you scale, so you do not undersize a server that is quiet only between known peaks.

1. Pull the right-sizing recommendations and the spend behind them

List Azure Advisor's cost recommendations that target PostgreSQL flexible servers and attach each server's current compute spend. Rank by the recurring saving available, the price gap between the current SKU and a halved one, so the largest, most idle servers are addressed first. Treat the recommendation list as the candidate set, not the final decision.

2. Confirm the low utilisation is steady-state

For each flagged server, check 'cpu_percent' and 'memory_percent' in Azure Monitor over a window long enough to span its normal cycles, a full month if the workload has a month-end batch. A server that is genuinely idle throughout is a risk-free cut. A server that is quiet most of the time but peaks predictably needs a sizing decision against that peak, not a reflex halving.

3. Scale to the right SKU, expecting a brief restart

Move the server to a smaller SKU in the same tier, or down a tier (for example General Purpose to Burstable) for a workload that does not need continuous capacity. Scaling compute restarts the server, so do it in a maintenance window. Remember that moving down to Burstable is not reversible by in-place scaling, so be sure about that move before you make it.

4. Make right-sizing routine, then layer reservations

Bake an Advisor cost-recommendation review into the regular cost cycle so right-sizing happens continuously rather than once. Where a right-sized server runs a steady, long-lived workload, apply a reserved-capacity commitment on top, sized to the new SKU, to stack a further documented saving of up to 40 per cent for one year or up to 60 per cent for three on the already-reduced footprint.

# 1. Confirm the server has genuinely sat idle: average CPU over the last 7 days.
az monitor metrics list \
  --resource "$SERVER_ID" \
  --metric cpu_percent \
  --interval PT1H \
  --aggregation Average \
  --start-time "$(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ')" \
  --query "value[0].timeseries[0].data[?average > \`20\`] | length(@)" -o tsv
# A low count of hours above 20% CPU confirms steady-state idle: safe to scale down.

# 2. Right-size: drop General Purpose 4 vCores to Burstable. --yes accepts the restart.
az postgres flexible-server update \
  --resource-group rg-data \
  --name reporting-pg-prod \
  --tier Burstable \
  --sku-name Standard_B1ms \
  --yes

Quick quiz

Question 1 of 5

Azure Advisor raises a right-sizing recommendation against a PostgreSQL flexible server. What is it telling you?

Keep learning

Go deeper on how PostgreSQL flexible-server compute is priced, how Advisor surfaces right-sizing, and how to scale safely.

You can now treat right-sizing as one capability rather than a scatter of Advisor flags: pull the cost recommendations against your PostgreSQL flexible servers, rank them by the recurring saving behind each, confirm the low utilisation is genuine, scale the idle servers down with the az CLI or Bicep, and make the review a routine so the database bill keeps tracking actual usage. Right-size first, then layer reservations on the smaller footprint.

Back to the library

Right-sizing PostgreSQL flexible servers: the savings view

A recurring line on the Azure bill you can cut today with no new spend and a near-immediate payback

This is the rare cost item where the remediation costs nothing and the saving is recurring. Scaling a flexible server down does not buy anything; it stops you buying compute the database never uses. Advisor's own steer on the equivalent recommendation is to halve the vCores, and because PostgreSQL flexible-server compute is billed per vCore-hour, halving the compute size of a steady-state idle server roughly halves its compute bill, every hour, for as long as the server runs. The payback is effectively immediate: the change takes minutes and the lower rate applies from the next hour.

Frame each Advisor right-sizing recommendation as a recurring annual saving, not a one-off ticket. A staging server overprovisioned at eight vCores that only ever needs two is not an eight-versus-two argument once; it is the price difference multiplied by 730 hours a month, every month, until it is fixed. Rank the recommendations by the monthly compute spend behind each server so the largest, most idle servers are scaled first and the saving lands soonest.

The trade-off is genuinely one-sided for the idle servers and only needs a judgement call on the busy ones. Advisor surfaces servers that have been underutilised for weeks, so for those there is no performance to trade away. The discipline is to separate the genuinely idle servers, which are a risk-free cut, from the servers that look quiet only because you caught a trough before a known peak, which need a sizing decision rather than a reflex scale-down.

This lesson is for the finance partner who sees managed-database spend climbing and wants to know how much of it is paying for idle compute. It covers why right-sizing is a zero-cost change with a recurring saving, how to rank Advisor's recommendations by the spend behind each server, and how to tell a risk-free cut from a sizing call that needs the engineering team's judgement.

Fun fact

The half that nobody noticed

How a finance partner frames the right-sizing decision

Priya is the finance partner watching managed-database spend tick up quarter on quarter. The cost report shows Advisor has raised right-sizing recommendations on two PostgreSQL flexible servers, and the instinct is not to wave them through as a single ticket; it is to put a recurring number against each one. Scaling a server down buys nothing, so there is no spend to approve. The figure that matters is the saving: the compute price difference between the current SKU and the recommended one, multiplied by 730 hours a month, recurring until something changes.

Priya asks the team to map each flagged server to its workload and its current monthly compute spend. The staging server is overprovisioned at eight vCores and only sees a developer a few times a week, so it is a risk-free cut and the largest single saving. The reporting server runs quiet most of the day but drives a heavy month-end batch, so Advisor's flag reflects the average rather than the peak, and that one needs a sizing decision, not a reflex halving. The finance pack reads: 'One server scales down today for a recurring monthly saving at no new spend; one needs the team to size it for its month-end peak; the only thing between us and the saving is minutes of engineering time.'

Why right-sizing belongs on the cost review

The savings model here is unusually clean. Right-sizing an idle server costs nothing in Azure spend, and the saving recurs every hour for the life of the workload, so a few minutes of engineering time converts into a standing reduction on the bill. For a steady-state idle server, halving the compute size roughly halves its compute charge, and that delta repeats across 730 hours a month with no further action.

The finance role is to make the recurring nature visible. An Advisor recommendation dismissed once is not a closed ticket; it is a monthly saving forgone indefinitely. Attach the price difference between current and recommended SKU to each flagged server, multiply by the hours, and rank the recommendations by annualised saving so the biggest, most idle servers are scaled first. The one nuance to respect is sequencing with commitments: right-size the server before applying any reserved-capacity purchase, so the reservation is sized to the workload's real footprint rather than locking in the oversized one.

What finance can do about oversized servers

Finance cannot resize a server, but it owns the framing that turns a list of dismissable Advisor recommendations into a ranked, recurring saving with a near-immediate payback. Three levers.

1. Quantify each recommendation as an annualised saving

Make explicit that right-sizing costs nothing and the saving recurs. For each flagged server, attach the compute price difference between its current SKU and the recommended one and multiply by 730 hours a month. A halved server is roughly half its compute bill, every month, indefinitely. Reported as an annualised figure, a scatter of Advisor recommendations becomes a single number worth chasing.

2. Rank by saving and protect against the false-idle trap

Order the work by the recurring saving available, biggest and most idle first, so the money lands soonest. The one discipline to insist on is that the team confirms steady-state low utilisation before scaling: a server that looks idle on average but drives a month-end peak is a sizing decision, not a halving. Separating the risk-free cuts from the sizing calls keeps the savings real and avoids an undersize that triggers a costly emergency scale-up.

3. Sequence right-sizing before any reservation

If the estate is considering reserved capacity for its databases, insist that servers are right-sized first. A reservation locks in a capacity commitment, so committing to an oversized server bakes the waste in for one or three years. Right-size to the real footprint, then reserve on top of the smaller SKU to stack the documented reservation saving on the already-reduced base.

Quick quiz

Question 1 of 5

Advisor flags a PostgreSQL flexible server for right-sizing. As the finance partner, how should you size the opportunity?

Keep learning

Go deeper on how PostgreSQL flexible-server compute is priced, how Advisor surfaces right-sizing, and how to scale safely.

You have finished the finance view of right-sizing. You know the model is one-sided for the idle servers: the change costs nothing and the saving recurs every month for the life of the workload. Next time Advisor raises a right-sizing recommendation, you will put an annualised number against it, rank by saving, insist the team confirms steady-state idle before scaling, and sequence right-sizing ahead of any reservation so the commitment fits the real footprint.

Back to the library

Right-sizing PostgreSQL flexible servers: the headline

Whether the managed-database bill is sized to what the workloads use or to what someone guessed at provisioning time

Managed databases are one of the steadiest lines on an Azure bill, which is exactly why oversizing on them quietly compounds. A flexible server provisioned too large keeps charging the larger rate every hour for the life of the workload, and nobody notices because the bill simply looks normal. Azure Advisor already flags the servers that have run underutilised for weeks; the open question for leadership is whether anyone is acting on those flags.

The decision here is not a cut that risks the service. Advisor only raises the recommendation after sustained low utilisation, and Microsoft's own guidance is that the compute can be reduced without significant performance impact for these servers. The defensible end state is that right-sizing is a routine, owned part of the cloud-cost cycle: Advisor recommendations are reviewed, the idle servers are scaled down, and any server kept large is kept large on purpose with a reason on record.

This is a savings and ROI decision, not a security one. The money saved is recurring and the cost of capturing it is engineering minutes. The leadership move is to make sure the saving is actually being banked rather than left sitting in a dismissed Advisor recommendation.

A short read for the leader who wants the managed-database bill sized to actual usage rather than to provisioning-time guesses. It covers why right-sizing idle servers is a savings decision with near-immediate payback, why Advisor having already flagged the servers takes the performance risk off the table, and what it looks like when right-sizing is a routine part of the cost cycle rather than a one-off cleanup.

Fun fact

The half that nobody noticed

What it looks like when the database bill is sized to usage, not to guesses

At a cost review the CFO asked the obvious question: managed-database spend is up, are we paying for capacity we use? The honest answer at the time was that nobody was sure, because the servers had been sized during a growth push and never revisited, and Azure Advisor's right-sizing recommendations were sitting in the portal unread.

The team's response was to stop treating right-sizing as a one-off cleanup and make it part of the cost cycle. They worked through Advisor's recommendations, confirmed which servers had genuinely sat idle for weeks, scaled those down, and left a documented note on the one server kept large for a month-end batch. The next review answered the CFO's question with a number: a recurring monthly saving banked from servers that had been charging for compute they never used, captured in an afternoon at no new spend. The shift, from a bill sized by provisioning-time guesses to a bill sized by actual usage with the exceptions named, is the ROI signal this capability delivers.

Why this is a standing ROI item, not a one-off cut

Almost every estate carries some managed-database overspend for the same reason: servers are sized at creation for a forecast and rarely revisited, so the bill silently holds the high-water mark of past guesses. Right-sizing is the routine that brings the bill back to actual usage, and because Advisor already identifies the candidates, the cost of running the routine is small.

The return is recurring and the risk is low: Advisor only flags servers after sustained low utilisation, and the compute can be reduced without significant performance impact for those servers. This is the kind of saving leadership should want made a habit rather than a project, banked every month rather than rediscovered in an annual cost-cutting drive.

The leadership move on right-sizing

The executive handle is not to approve each scale-down individually; it is to require that Advisor's cost recommendations are acted on as a routine and that any server kept large is kept large on purpose.

1. Make Advisor cost recommendations a standing agenda item

Ask that the Advisor Cost tab is reviewed on a regular cadence and that right-sizing recommendations are either actioned or have a recorded reason for being kept. A recommendation dismissed silently is a recurring saving forgone, so the requirement is that none is dismissed without a one-line rationale on the record.

2. Ask for the saving in money, not in ticket counts

The proof this is working is not 'we closed some Advisor items.' It is a reported recurring saving: the annualised compute reduced by the right-sizing done this cycle. Because the change costs nothing and the payback is near-immediate, the only question worth asking is how much standing spend was removed from the bill.

3. Treat deliberately large servers as named, owned exceptions

Some servers are sized large for a real peak, a month-end batch or a known seasonal load. That is fine. The leadership requirement is that each is a deliberate, documented decision with an owner and the peak it is sized for, not a forgotten provisioning guess. The goal is not the smallest possible servers; it is zero servers oversized by accident.

Quick quiz

Question 1 of 5

At a cost review you ask whether the managed-database bill is sized to actual usage. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how PostgreSQL flexible-server compute is priced, how Advisor surfaces right-sizing, and how to scale safely.

Two takeaways. Right-sizing idle servers is a savings decision with a near-immediate payback and low risk, because Advisor only flags them after sustained low utilisation, so it is the kind of saving to make routine rather than rediscover. And the defensible end state is not 'the bill looks normal'; it is Advisor cost recommendations reviewed on a cadence, idle servers scaled down, and every deliberately large server kept large on purpose with a reason on record.

Back to the library

Part of the learning path Right-size your Azure compute

Right-size underutilised Azure Database for PostgreSQL servers

Right-sizing PostgreSQL flexible servers: the basics

The half that nobody noticed

Finding underutilised PostgreSQL servers across a subscription

How Azure Advisor decides a flexible server is underutiliseddeep dive

What is the impact of leaving servers oversized?

How do you right-size a flexible server safely?

1. Pull the right-sizing recommendations and the spend behind them

2. Confirm the low utilisation is steady-state

3. Scale to the right SKU, expecting a brief restart

4. Make right-sizing routine, then layer reservations

Quick quiz

Keep learning

Right-sizing PostgreSQL flexible servers: the savings view

The half that nobody noticed

How a finance partner frames the right-sizing decision

Why right-sizing belongs on the cost review

What finance can do about oversized servers

1. Quantify each recommendation as an annualised saving

2. Rank by saving and protect against the false-idle trap

3. Sequence right-sizing before any reservation

Quick quiz

Keep learning

Right-sizing PostgreSQL flexible servers: the headline

The half that nobody noticed

What it looks like when the database bill is sized to usage, not to guesses

Why this is a standing ROI item, not a one-off cut

The leadership move on right-sizing

1. Make Advisor cost recommendations a standing agenda item

2. Ask for the saving in money, not in ticket counts

3. Treat deliberately large servers as named, owned exceptions

Quick quiz

Keep learning

Related cost lessons