Azure PostgreSQL FlexibleServer is stuck for days now after trying to scale up and cannot be recovered.

Question

Azure PostgreSQL FlexibleServer is stuck for days now after trying to scale up and cannot be recovered.

Karol Marek 20

We created an Azure Database PostgreSQL Flexible Server and started with a burstable tier first to setup everything and do some tests before we decide to go live with the new features on production. Few days before going live we decided to scale up from Burstable tier (B1) to General Purpose. The deployment (scale-up) operation got stuck. After 2h nothing changed, so we already had an issue with the whole production delivery plan. After another few hours (I think around 6h) we tried to cancel the deployment and it got cancelled, but the PostgreSQL FlexibleServer is still stuck. We cannot do anything with it - we get a message that it is in 'Updating' state. Right now the production delivery has been postponed by a few weeks because of this issue.

The only thing we can do is Restore it to a new server, which we did just to avoid recreating everything from scratch. However, we cannot recover it at the same place, because we cannot delete the one that is stuck. In theory the delete button is active, but private endpoint has to be removed first and we cannot do it when the server is in 'Updating' state.

We have searched on the web and found plenty of similar issues on this platform, so it seems like an often situation. That's quite strange to be honest and we are really worried if we can use Azure PostgreSQL FlexibleServer on production if it's so unreliable.

We tried already all of the recommendations from other threads, we haven't found any locks, we cannot stop or start the service while it's in 'Updating' state, we cannot delete it.

Can you please fix the service, unlock it or whatever is needed to make it work or just remove it so that we can create a new one?
Can you have a closer look at the PostgreSQL FlexibleServer deployment please? Having in mind the amount of issues people are having with it, I would suggest searching for the root cause and fixing it if you don't want people quitting to other cloud providers. It should be a simple operation to a scale it up - we were scaling up Virtual Machines and Azure SQL Databases or Azure SQL Elastic Pools hundreds of times in the past and hardly ever had any issues, but most of all they were always recoverable.
Aside question: why do I need to agree on receiving tips and offers from Microsoft just to post a technical question or issue? I upgraded Support plan to a paid one to create a technical ticket on Azure, but then I heard I should upgrade higher to Standard or post this message. It's been over 24h since I created a ticket on Azure Support and I haven't received any answer. That's why I'm creating this question.

User's image

Ganesh Chelluri 195 Reputation points Microsoft External Staff Moderator

2026-09-29T18:56:00.3866667+00:00
Hi @Karol Marek ,

Apologies for the delay.

The PostgreSQL Flexible Server remained in the Updating state after the Burstable-to-General-Purpose scaling operation was cancelled. While the server remains in this state, please do not submit additional scale, restart, stop/start, delete, or private-endpoint operations against the affected server.

Restoring the database to a new Flexible Server is the available customer-controlled recovery path. Please complete the following validation on the restored server:

Confirm that the expected databases and recent data are present.

Validate application read and write operations.

Compare the restored server parameters with the original server and apply any required values.

Recreate or validate the required firewall, private-networking, private DNS, and identity configuration.

Update application connection strings and secrets to reference the restored server.

Keep the original server unchanged until the restored environment has been fully validated.

The available evidence confirms that the original server is blocked in a management-plane Updating state. It does not identify why the original scaling workflow failed. Cancelling the deployment did not return the server to Ready.

Please keep subscription IDs, complete resource IDs, operation IDs, and correlation IDs in the private message rather than posting them publicly.
Karol Marek 20 Reputation points

2026-09-29T21:03:34.4866667+00:00

Hi @Ganesh Chelluri ,

Thanks for reaching out. We haven't been performing any additional operations for days now. In fact we've been waiting patiently for a few hours after starting the scale-up operation had been started. Since nothing changed, we tried to start or stop it and then around 6h after initiating the scale-up, we decided to cancel the deployment. Therefore, I have doubts if cancelling the deployment is the reason here. More probably the scale-up itself was already blocked and cancelling didn't change a thing. After cancelling the deployment we obviously tried to run some start or stop commands and other suggestions found on the web (also on this Q&A), but it was long time ago and for the past few days we did not do anything to the server except from viewing it in the Azure Portal to check if maybe magically it got healed. We created a backup last week and since then we are just waiting and trying to contact the Support Team as suggested by @Praveen Sreeram .

Anyway, for the past few days we didn't run any operations against the PostgreSQL server, which is still blocked with the 'Updating' state. We do have a backup and it has been verified. Please either restore the server to a 'Ready' state or just remove it. Can you let me know how long it can take?

Regards

Karol
Karol Marek 20 Reputation points

2026-09-30T13:10:52.79+00:00

Hi @Ganesh Chelluri ,

I hope you are doing well. Do you think there is a chance to solve the issue soon and get the server either back to a 'Ready' state or get it removed?

Regards

Karol
Karol Marek 20 Reputation points

2026-10-01T11:17:07.6233333+00:00

Hi Team!

Any news about the issue?

Answer accepted by question author

Smaran Thoomu 35,875 Microsoft External Staff Moderator

Hi @Karol Marek

Thank you for your patience while we worked through this issue.

We engaged our Engineering team to investigate the affected PostgreSQL Flexible Server. The underlying instance was found to be in a deallocated state, and Engineering initiated the VM startup operation.

Following the recovery, the PostgreSQL service became available again and the server returned to a healthy state.

You have also confirmed that the service is now available and that you were able to reconfigure the required operations to use the PostgreSQL server restored from your backup. You subsequently removed the affected server successfully.

The issue is now resolved.

Thank you again for your patience and cooperation while we worked with Engineering to recover the service.

0 comments

1 additional answer

Your answer

Ganesh Chelluri 195 Reputation points Microsoft External Staff Moderator

2026-09-29T18:56:00.3866667+00:00

Hi @Karol Marek ,

Apologies for the delay.

The PostgreSQL Flexible Server remained in the Updating state after the Burstable-to-General-Purpose scaling operation was cancelled. While the server remains in this state, please do not submit additional scale, restart, stop/start, delete, or private-endpoint operations against the affected server.

Restoring the database to a new Flexible Server is the available customer-controlled recovery path. Please complete the following validation on the restored server:

Confirm that the expected databases and recent data are present.

Validate application read and write operations.

Compare the restored server parameters with the original server and apply any required values.

Recreate or validate the required firewall, private-networking, private DNS, and identity configuration.

Update application connection strings and secrets to reference the restored server.

Keep the original server unchanged until the restored environment has been fully validated.

The available evidence confirms that the original server is blocked in a management-plane Updating state. It does not identify why the original scaling workflow failed. Cancelling the deployment did not return the server to Ready.

Please keep subscription IDs, complete resource IDs, operation IDs, and correlation IDs in the private message rather than posting them publicly.
Karol Marek 20 Reputation points

2026-09-29T21:03:34.4866667+00:00

Hi @Ganesh Chelluri ,

Thanks for reaching out. We haven't been performing any additional operations for days now. In fact we've been waiting patiently for a few hours after starting the scale-up operation had been started. Since nothing changed, we tried to start or stop it and then around 6h after initiating the scale-up, we decided to cancel the deployment. Therefore, I have doubts if cancelling the deployment is the reason here. More probably the scale-up itself was already blocked and cancelling didn't change a thing. After cancelling the deployment we obviously tried to run some start or stop commands and other suggestions found on the web (also on this Q&A), but it was long time ago and for the past few days we did not do anything to the server except from viewing it in the Azure Portal to check if maybe magically it got healed. We created a backup last week and since then we are just waiting and trying to contact the Support Team as suggested by @Praveen Sreeram .

Anyway, for the past few days we didn't run any operations against the PostgreSQL server, which is still blocked with the 'Updating' state. We do have a backup and it has been verified. Please either restore the server to a 'Ready' state or just remove it. Can you let me know how long it can take?

Regards

Karol
Karol Marek 20 Reputation points

2026-09-30T13:10:52.79+00:00

Hi @Ganesh Chelluri ,

I hope you are doing well. Do you think there is a chance to solve the issue soon and get the server either back to a 'Ready' state or get it removed?

Regards

Karol
Karol Marek 20 Reputation points

2026-10-01T11:17:07.6233333+00:00

Hi Team!

Any news about the issue?

Answer 1

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

1 deleted comment

Comments have been turned off. Learn more