PostgreSQL flexible server: out of the delegated subnet, on to private endpoints

Why the move can pay off

Microsoft now calls Private Link the recommended alternative to VNet integration. The reasons are in the limitations of VNet integration:

• A server in a delegated subnet cannot be moved to another VNet or subnet.
• The subnet cannot be enlarged once resources are in it.
• Nothing else may live in the delegated subnet, and Private Link is not available there.

With a private endpoint, the server sits outside your network and is reached through a private IP address. Several endpoints in different VNets are possible, as is access from on-premises over VPN or ExpressRoute. According to Microsoft, high availability, read replicas and major version upgrades also work with private endpoints.

More on this: Standard service endpoint: when it replaces private endpoints and when it does not

What happens during the switch

The order within the maintenance window

• Before: choose the subnet for the private endpoint and link the private DNS zone privatelink.postgres.database.azure.com to every VNet that needs access. With on-premises DNS servers, check the forwarding.
• Before: check connection strings. Microsoft advises always using the fully qualified name because the IP address may change.
• In the window: start the change and wait until the state moves from Updating to Ready.
• Right after: create the private endpoint and check that the server name resolves to the private address.
• Afterwards: test applications, backup tools and monitoring.

az postgres flexible-server migrate-network \
  --resource-group <resource_group> \
  --name <server>

az postgres flexible-server show \
  --resource-group <resource_group> \
  --name <server> \
  --query "state"

In the portal, the option under Networking is called “Public access (allowed IP addresses) and private endpoints”. The confirmation dialog spells out the consequences once more.

Three places where it goes wrong

Terraform is the most dangerous. If the configuration still contains delegated_subnet_id, Terraform plans a new server, because that value forces a replacement. In addition, the provider sets public_network_access_enabled to true when omitted and would reopen public access. Adjust both before the next apply and confirm in the plan that no replacement is scheduled.

Logical replication can break. Subscribers open the connection to the publisher themselves. The private path through the delegated subnet disappears, so every subscriber has to reach the private endpoint, through the same VNet, peering, VPN or ExpressRoute.

IP addresses hard-coded in applications, firewalls or scripts point nowhere after the change. That includes rules in firewalls at on-premises sites.

Finding affected servers

The Azure Resource Graph query lists every flexible server that still sits in a delegated subnet.

resources
| where type =~ 'microsoft.dbforpostgresql/flexibleservers'
| extend subnet = tostring(properties.network.delegatedSubnetResourceId)
| where isnotempty(subnet)
| project name, resourceGroup, location, version = tostring(properties.version), subnet
| order by version asc

The version column also shows which servers need a major version upgrade soon anyway. For PostgreSQL 14, paid Extended Support begins on 1 February 2027. Planning both changes together means coordinating with the application owners only once, even if it remains two maintenance windows.

More on this: PostgreSQL 14 on Azure: from 1 February 2027 every vCore costs extra

Is it worth it for every server?

No. A server used only by applications in the same VNet that does not need to grow keeps working with VNet integration at no disadvantage. The move becomes interesting when access from several VNets or from on-premises is needed, the subnet is too small or the network architecture is to be standardised on private endpoints. An architecture review sorts each server into one of these groups, and your team carries out the change in the maintenance window.