Change from virtual network integration to a private endpoint-capable network configuration in Azure Database for PostgreSQL flexible server

Azure Database for PostgreSQL deployed with private access uses virtual network integration to place the server in a delegated subnet within your virtual network. You can change these servers to a network configuration that supports private endpoints. Private endpoints provide secure connectivity through Azure Private Link, so you can access your server over a private IP address within your virtual network. This change replaces virtual network integration with private endpoint support, giving you more flexibility in network design while maintaining private connectivity.

This article walks you through how to change your network configuration, what to expect during the process, and how to restore connectivity after the change.

Details to know in advance

Before you change your network configuration, review how the change affects public access, connectivity, backups, and logical replication.

• Public access settings:

  • After the change, public access is disabled by default. To allow public access, enable public access and then add firewall rules to permit inbound traffic.

• If you use Terraform to manage the server, update your configuration after the change. For more information, see Update Terraform scripts.

• The change typically takes up to 20 minutes. During this time, the server is in the Updating state.

• Connectivity impact:

  • The server is typically inaccessible for up to 10 minutes. During that time, the operation closes existing database connections and rejects new connection attempts.

• Backup and restore:

  • All backups captured before the change, including geo-redundant backups, remain available after the change.

• Logical replication:

  • If the server is a logical replication publisher, the change might break its subscribers' connections, depending on your setup. Subscribers always initiate the connection to the publisher, and the private network path that virtual network integration gave them ends when the server leaves its delegated subnet.
  • After the change, make sure each subscriber can reach the server's private endpoint, for example from the same virtual network, through virtual network peering, or over a VPN or Azure ExpressRoute connection.

Steps to change your network configuration

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"

Configure the server after the change

After the change finishes, restore connectivity to the server and update any infrastructure-as-code templates to match the new network configuration.

Restore connectivity

After the change, the server is inaccessible until you set up at least one of these connectivity options:

• Add a private endpoint connection.
• Enable public access if it's disabled, and then add firewall rules for the clients that need to connect.

Update Terraform scripts

After the change, the server no longer uses virtual network integration. If you manage the server with Terraform, update your configuration:

• Remove delegated_subnet_id from the azurerm_postgresql_flexible_server resource. If the configuration still sets it, Terraform plans to replace the server, because changes to this argument force a new server.
• Set public_network_access_enabled to match the server's public access setting after the change. The provider defaults this argument to true, so if you omit it, Terraform tries to enable public access.
• Run terraform plan and confirm that the plan doesn't replace the server before you apply it.

Related content

• Add private endpoint connections
• Enable or disable public access
• Add firewall rules
• Networking with Private Link