In this blog post Modernise PostgreSQL Private Endpoints Without Rebuilding Apps we will explain how organisations can improve Azure database networking without copying data into a new server or redesigning every connected application.
Many businesses have an Azure Database for PostgreSQL Flexible Server that works reliably but is tied to an older network design. Changing that design previously meant considering a second server, data migration, application cutover and a rollback plan—all to solve a networking problem.
As of November 2026, Microsoft supports an in-place change from virtual network integration to a configuration that supports private endpoints. This can remove much of the rebuilding work, but it is not a zero-risk button. DNS, routing, application dependencies and a short service interruption still need careful planning.
What has changed for PostgreSQL Flexible Server
Azure Database for PostgreSQL Flexible Server is Microsoft’s managed version of the PostgreSQL database. Microsoft handles the underlying infrastructure, backups, patching and optional high availability, while your team remains responsible for the data, application and network design.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingMany existing servers use virtual network integration. In plain English, the database is placed inside a dedicated section of your Azure network called a delegated subnet. This provides private access, but it also connects the database closely to that particular network structure.
The newer option uses Azure Private Link and private endpoints. A private endpoint gives the database a private IP address inside a network you control, allowing approved applications to reach it without exposing the connection to the public internet.
Microsoft now allows eligible VNet-integrated servers to change to a private endpoint-capable configuration in place. The database server and its existing backups are retained, avoiding a full data migration solely to modernise the network.
How the private endpoint technology works
A private endpoint is effectively a secure network doorway to one specific Azure service. It creates a network interface with a private IP address in your chosen subnet, then maps that interface to your PostgreSQL server through Azure Private Link.
Traffic travels across Microsoft’s private backbone rather than taking a normal public internet route. Applications in connected Azure networks—or in an office or data centre connected through a VPN or ExpressRoute—can use that private path.
DNS is the part that makes this work without major application changes. DNS is the service that translates a database name into the IP address applications use to reach it.
Your applications should continue using the PostgreSQL server’s full host name rather than a hard-coded IP address. Correctly configured private DNS then returns the private endpoint’s IP address to authorised networks. This means connection strings can usually remain unchanged even though the path behind them has changed.
This is also why DNS mistakes cause so many private endpoint outages. The endpoint may be healthy, but an application using the wrong DNS server can still be directed to an unreachable public address—or fail to resolve the database name altogether.
Why modernise if the current design still works
Separate the database from one network layout
A VNet-integrated server depends on a delegated subnet. That can become restrictive when networks are consolidated, subscriptions are reorganised or applications move into a hub-and-spoke design, where several smaller networks connect through a central network.
Private endpoints let the database service remain separate while access is provided through carefully selected networks. The business outcome is greater flexibility when modernising applications, completing an acquisition or separating production environments.
Avoid migration work that adds little business value
Rebuilding a server can involve data replication, testing, cutover coordination and temporary duplicate infrastructure. It may also consume senior engineering time while creating a new source of operational risk.
An in-place network change reduces that scope. It does not remove the need for testing, but it can turn a database migration project into a controlled networking change.
Reduce unnecessary public exposure
After the network configuration change, public access is disabled by default. Once private endpoints and DNS are working, applications can connect through private network paths without requiring broad internet-facing access.
This does not automatically make the database secure. Strong identities, encryption, patching, monitoring and appropriate PostgreSQL permissions are still required. However, reducing the available network paths makes accidental exposure less likely.
Private access can also support Essential Eight discussions. Essential Eight is the Australian Government’s cybersecurity framework that many organisations use to improve security maturity. It does not specifically require PostgreSQL private endpoints, but limiting exposure and controlling access can strengthen the wider security and compliance position.
A practical business scenario
Consider a 200-person software company with production applications, reporting tools and support systems connected to one PostgreSQL Flexible Server. The server was originally placed in a delegated subnet, but the company now wants to centralise connectivity through an Azure hub network.
Under the previous approach, the team might have created a replacement PostgreSQL server, copied the databases, synchronised final changes and moved every application during a weekend cutover. That introduces data migration risk even though the database platform itself does not need replacing.
With the in-place option, the company can focus on the actual requirement: changing how systems reach the existing server. It still needs a maintenance window, private endpoint deployment, DNS updates and application testing, but it avoids running and validating a second database platform.
The result is less project effort, fewer moving parts and a smaller chance of data differences appearing during cutover.
Plan the change as a controlled outage
The conversion is irreversible. Once the server leaves the VNet-integrated model, it cannot simply be placed back into that delegated subnet. Treat the decision as an architecture change, not a routine portal setting.
Microsoft advises that the overall update can take up to 20 minutes, with the database typically inaccessible for up to 10 minutes. Existing connections may be closed and new connections rejected during that period.
A safe plan should include these steps:
- Map every dependency. Include applications, reporting platforms, integration services, monitoring tools, deployment pipelines, administrator workstations and logical replication subscribers.
- Design the destination first. Decide which virtual network and subnet will contain the private endpoint, and confirm how other networks and on-premises systems will route to it.
- Prepare private DNS. Confirm that Azure workloads, branch offices and remote administrators will resolve the PostgreSQL host name to the expected private IP address.
- Agree on a maintenance window. Allow time for the network conversion, private endpoint configuration, approval, DNS propagation and application validation.
- Test business transactions. A successful database login is useful, but it does not prove that ordering, payroll, reporting or customer-facing workflows operate correctly.
- Update automation. Terraform, deployment templates, monitoring rules and recovery documents must reflect the new architecture.
For a deeper look at DNS and routing preparation, see our guide to moving PostgreSQL to Azure private endpoints without surprises.
Use simple tests before approving the change
Run tests from every important network location, not just from an administrator’s virtual machine. The following examples check name resolution, port access and a real database query.
nslookup yourserver.postgres.database.azure.com
Test-NetConnection yourserver.postgres.database.azure.com -Port 5432
psql "host=yourserver.postgres.database.azure.com port=5432 dbname=appdb sslmode=require" \
-c "SELECT current_database(), current_timestamp;"The DNS result should show the intended private path, port 5432 should be reachable, and the PostgreSQL query should complete using the normal application host name. Avoid changing applications to use the endpoint’s numeric IP address because that creates a fragile long-term dependency.
Do not overlook replication and recovery
Existing backups, including previously captured geo-redundant backups, are retained through the network change. Even so, confirm backup health and document the recovery process before starting.
Logical replication needs special attention. If the PostgreSQL server publishes changes to subscribers, those subscribers must be able to reach the new private endpoint through the same network, a peered network, VPN or ExpressRoute connection.
It is also sensible to separate this work from a major PostgreSQL version upgrade. If both changes are necessary, use pre-upgrade checks to reduce PostgreSQL upgrade risk, then schedule each change independently so troubleshooting remains clear.
Modern networking without unnecessary rebuilding
The biggest benefit is not simply that private endpoints are newer. It is that organisations can now improve network flexibility and reduce public exposure without automatically turning the work into a full database migration.
The safest projects still begin with dependency discovery, DNS design and business-level testing. A short planned interruption is usually easier to manage than discovering after cutover that a reporting service, remote office or replication subscriber can no longer find the database.
CloudProInc brings more than 20 years of enterprise IT experience to this type of work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations connect Azure architecture, cybersecurity and practical operational planning without the overhead of a large, faceless provider.
If your PostgreSQL server is tied to an ageing network design, or you are unsure whether private endpoints will simplify or complicate your environment, we are happy to review the current setup and identify the safest path forward—no strings attached.