How to Resolve the Call to Microsoft.DBforPostgreSQL/flexibleServers failed Error

Issue

You receive the following error message:

Call to Microsoft.DBforPostgreSQL/flexibleServers failed. Error message: The given server {serverIdentifier} does not support private endpoint feature. Please create a new server that is private endpoint capable. Refer to https://aka.ms/pgflex-pepreview for more details

Environment

All database connectors Connection method: Private networking

Understanding the problem

Azure Database for PostgreSQL Flexible Server supports Private Endpoints only when the server is created with Private access (VNet integration). The error means {serverIdentifier} was created with Public access (allowed IP addresses), or before Private Endpoint was available for that config, and you can’t switch a Flexible Server from Public to Private after creation.

Causes and solutions

The existing server isn’t Private Endpoint–capable because its networking mode is Public.

Create a new Flexible Server configured for Private access (VNet integration) in a delegated subnet (Microsoft.DBforPostgreSQL/flexibleServers), migrate data, then use a Private Endpoint to reach it.

Resolution

1. Plan the new server:

   • In Networking, choose Private access (VNet integration).
   • Select the VNet and a delegated subnet dedicated to PostgreSQL Flexible Server, with no other resources.
   • Match or set desired compute, storage, version, and admin credentials.

2. Create the PostgreSQL Flexible Server with private access:

   In the Azure Portal

   1. Go to Azure Database for PostgreSQL flexible servers > + Create.
   2. Complete Basics and Compute + storage.
   3. In Networking, set Connectivity method to Private access (VNet integration). Choose your VNet and delegated subnet (or Create new subnet).
   4. Finish Security, Tags, then click Review + create.

   Using Azure CLI

   Use the az postgres flexible-server create command. The key parameters for networking are --vnet and --subnet.

     # Example: Create a new VNet and a delegated subnet first if you don't have them
     az network vnet create \
         --resource-group <your-resource-group> \
         --name <your-vnet-name> \
         --address-prefixes 10.0.0.0/16
   
     az network vnet subnet create \
         --resource-group <your-resource-group> \
         --vnet-name <your-vnet-name> \
         --name <your-delegated-subnet-name> \
         --address-prefixes 10.0.1.0/24 \
         --service-endpoints Microsoft.Web \ # Example for web app integration, not strictly for PG flexible server delegation but good practice
         --delegations Microsoft.DBforPostgreSQL/flexibleServers # <--- THIS IS CRITICAL FOR DELEGATION
   
     # Then, create the PostgreSQL Flexible Server with private access
     az postgres flexible-server create \
         --name {serverIdentifier}-new \ # Give it a new name
         --resource-group <your-resource-group> \
         --location <your-region> \
         --version 13 \ # Or your desired version
         --admin-user <your-admin-user> \
         --admin-password <your-admin-password> \
         --vnet <your-vnet-name> \
         --subnet <your-delegated-subnet-id-or-name> \ # Use the ID or name of the delegated subnet
         --private-dns-zone "privatelink.postgres.database.azure.com" # Highly recommended for Private DNS resolution
   

3. Migrate data (if needed):

   If {serverIdentifier} holds production data, move it to the new server using one of these:

   • pg_dump + psql - Export from the old server and restore to the new one.
   • Azure Database Migration Service (DMS) - Managed migration for larger or complex workloads.
   • Logical replication - Continuously sync to the new server, then perform a brief switchover.

4. Create the Private Endpoint:

   • After the new server is up, create a Private Endpoint targeting it.
   • Place the Private Endpoint in a different subnet from the server’s delegated subnet (same VNet or a peered VNet).