Azure PostgreSQL Flexible server network change

Question

Hi all,

Asking here as support seems to be handled by AI now and I've had no useful responses.

There does not appear to be any practical way to take a Postgres Flexible server that was created with public access and update/move/restore it to be on a private vnet.

• You can't change the existing server from public and put it on a vnet.
• You can't make start a replication to another server and promote that one because creating the replica does not allow you to change the networking settings.
• You can't restore the server to a new server because that does not allow you to change the networking settings.
• You can't use DMS to do an online copy to a new server, because you can only copy from Postgres Single to Postgres Flexible (despite what AI support told me!), not Postgres Flexible to Postgres Flexible (this is the second time in 5 years I've been caught out by restrictions in DMS. Last time I migrated to AWS and then migrated back - ridiculous).
• You can't do some magic with private endpoints if your database servers were created before private endpoints was a feature.

I have 8 production database servers that are stuck like this. What am I supposed to do? Run pg_dump manually to an Azure VM and then restore? Unworkable for production systems and uptime requirements.

Is there some option I've overlooked? Thanks!

Answer 1

Hi @Paul Donovan
You are correct that an existing Azure Database for PostgreSQL Flexible Server cannot be moved from Public access to Private access (VNet integration) in-place. Microsoft currently documents that moving a Flexible Server in or out of a virtual network isn't supported.

However, there is an important alternative that may avoid a database migration altogether: Private Link / Private Endpoint.

For a server originally deployed with Public access, you can create a Private Endpoint for the existing Flexible Server in a subnet of your VNet. The Private Endpoint provides a private IP in your VNet, and clients in the VNet, peered VNets, or connected on-premises networks can access the PostgreSQL server through that private endpoint.

The current networking model explicitly supports:

• Public-access Flexible Server + Private Endpoint
• Multiple Private Endpoints for the same server
• Private connectivity from VNets/peered VNets/on-premises
• Disabling public network access after the Private Endpoint is configured, if public connectivity is no longer required

So, if the requirement is "make the existing production PostgreSQL server privately reachable from our VNet", you do not necessarily need to create a second server and perform a database migration.

A typical approach would be:

1. Create a suitable subnet for Private Endpoints in the target VNet.
2. Create a Private Endpoint targeting the existing PostgreSQL Flexible Server.
3. Configure the appropriate Private DNS zone and VNet links so that the normal *.postgres.database.azure.com FQDN resolves to the private endpoint.
4. Test application connectivity through the private endpoint.
5. Once connectivity is confirmed, disable public network access on the PostgreSQL server if you want to eliminate public connectivity. Microsoft documents that disabling public access leaves connectivity through Private Endpoints.

This is different from Private access (VNet integration): the PostgreSQL server itself remains a public-access deployment, while Private Link provides private connectivity to it. Microsoft currently lists these as separate networking options.

Therefore, for the eight production servers, I would first evaluate Private Endpoint/Private Link rather than performing eight pg_dump/restore migrations.

If the actual requirement is specifically VNet integration/VNet injection (i.e., the PostgreSQL server itself must be deployed into a delegated VNet subnet), then there is currently no supported in-place conversion from public access to VNet integration. In that case, a migration to a newly created private-access Flexible Server is required.

Microsoft documentation: PostgreSQL Flexible Server networking overview Private Link for PostgreSQL Flexible Server Add a Private Endpoint to PostgreSQL Flexible Server