Azure Database for PostgreSQL: Server Stuck on Update State After Tier Change — Assistance Needed

Azure Admin 0 Reputation points
2026-11-12T09:30:28.9333333+00:00

Problem description

I am experiencing an issue where my Azure Database for PostgreSQL flexible server is stuck in the 'Updating' state after attempting to change the compute tier from General Purpose to Burstable. The server has remained in this state for over 20 hours, and the operation has not completed. I am seeking help to resolve this and understand the next steps.

Environment

Azure Database for PostgreSQL flexible server, region not specified in case details, original tier: General Purpose, requested tier: Burstable.

What I've already tried

I have not tried anything yet.

Current status

I am looking for assistance to escalate this issue to the relevant product team and to understand the expected time for recovery, as well as confirmation that my server data and backups are intact.

Azure Database for PostgreSQL
0 comments

1 answer

Sort by: Oldest
Most helpful Newest Oldest
  1. Allan Solomon Mejia 10,800 Reputation points
    2026-11-12T21:40:01.11+00:00

    Hi @Azure Admin

    Changing an Azure Database for PostgreSQL Flexible Server from General Purpose to Burstable is supported. A compute-tier change restarts the server and moves the workload to new compute while retaining the server’s storage. Regular scaling normally takes approximately 2–10 minutes, while near-zero-downtime scaling can reduce the interruption to under 30 seconds when applicable.

    An Updating state lasting more than 20 hours is therefore far outside the documented normal scaling duration and requires investigation by Microsoft.

    Recommended next steps:

    1. Don’t submit additional scale, restart, stop/start, or configuration operations while the current update remains active. Other management operations can be rejected while the server is processing an existing operation.
    2. Check Azure Service Health and Resource Health for an incident affecting PostgreSQL Flexible Server in the server’s region.
    3. Open the resource group’s Activity log, locate the tier-change operation, and retain:
      1. UTC start time
      2. correlation ID
      3. complete status/error details
      4. source and requested compute SKUs
      5. server resource ID
    4. Create an Azure technical support request for Azure Database for PostgreSQL Flexible Server → Compute scaling, stating that the server has remained in Updating for more than 20 hours. Ask support to inspect the in-progress resource-provider operation and safely complete or roll it back.

    Regarding the data, compute scaling involves detaching the existing storage and attaching it to the newly provisioned compute instance. Planned compute scaling isn’t expected to cause committed-data loss, although active connections are drained and uncommitted transactions are rolled back.

    Flexible Server also performs automatic snapshot and transaction-log backups according to the configured retention period. However, only Microsoft Support can confirm the exact state of this server and its most recent recoverable point while the platform operation is stuck.

    If the database is still reachable, consider taking a logical pg_dump as an additional precaution. Don’t delete the server or attempt a new deployment until Microsoft has inspected the pending operation.

    References:

    Scaling resources | Scale compute | Restart PostgreSQL Flexible Server

    PostgreSQL business continuity | Find Azure deployment errors | Backup and restore

    Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.