PostgreSQL Flexible Server stuck in "Updating" state for hours after a compute scale (General Purpose → Burstable)

A server remaining in Updating for more than four hours while continuing to serve database traffic normally is generally not consistent with a typical compute-tier change. Microsoft documents that compute scaling requires a restart of the server and should eventually complete with either a successful or failed provisioning state. [learn.microsoft.com], [learn.microsoft.com]

What stands out in your case is that:

• The db workload is still accessible.
• All management operations are blocked with 409 OperationInProgress.
• No corresponding completion or failure event appears in Activity Log.

Taken together, that suggests the resource provider's provisioning state and the actual database runtime state may have become out of sync, leaving a long-running management operation that never transitions to a terminal state.

Before assuming a platform fault, I would verify whether Azure still reports an active provisioning operation:

az postgres flexible-server show \
  --resource-group <resource-group> \
  --name <server-name> \
  --query "{state:state,sku:sku.name,tier:sku.tier}"

Also review the Azure Activity Log for the original update request and note:

• Operation name
• Start time (UTC)
• Correlation ID
• Current provisioning status

If the server continues to report Updating indefinitely while the database remains healthy and every management action returns 409, there is generally no customer-exposed operation to cancel or forcibly clear that provisioning state.

One interesting detail is the scale path being used:

General Purpose (Standard_D4ads_v5) -> Burstable (Standard_B1ms)

Azure Database for PostgreSQL Flexible Server supports moving between compute tiers, including Burstable, General Purpose, and Memory Optimized tiers. [learn.microsoft.com], [learn.microsoft.com]

However, this particular transition is also a significant downsize in both vCore and memory allocation. If Azure never reaches the restart/cutover phase successfully, the service can remain operational on the original compute while the provisioning workflow never completes. The fact that the workload is still running normally may indicate that the platform never committed the requested compute change rather than the database engine itself being unhealthy.

I would therefore focus on gathering evidence that the provisioning workflow is stalled:

• Current provisioning state from CLI
• SKU currently reported by the resource
• Activity Log correlation ID
• Exact UTC time the update was initiated
• Confirmation that all management operations consistently return 409

Those details should help determine whether the server is still actively processing the resize or whether the provisioning state is genuinely stuck.

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