Azure Database for PostgreSQL flexible server: Unable to connect Pgbouncer port using private endpoint - 6432

Question

Hi
wierd case
fresh Azure Database for PostgreSQL flexible server instance with Public access and Private endpoint
VNET with no NSG,FIREWALL or any other limitations

i CAN connect 5432 with no issues using both: Public and Private Point**

**but for 6432 i can only connect Public and not Private endpoint

Done:
-restart instance
-turn off\on built-in pgbouncer

Any ideas??
Thank you!

Answer 1

Hi!

After "Notification for Scheduled Maintenance to Azure Database for PostgreSQL" on 5/29/2026, 4:42:00 AM (UTC) PGBouncer doesn't connect

https://learn.microsoft.com/en-us/azure/postgresql/release-notes-maintenance/2026-april

I have a PostgreSQL flexible server that stopped working with pgbouncer after the May 29th update. I don't have NSG authentication and I'm on the same virtual network. It worked before the May 29th, but stopped after. Native psql authentication is being used.

Any ideas?

Answer 2

PgBouncer on Azure Database for PostgreSQL flexible server listens on port 6432 on the same VM as the database and supports both public and private access. There is no separate firewall or NSG configuration for 6432 versus 5432 at the server level; both ports are exposed through the same networking model (public endpoint and/or private endpoint) when PgBouncer is enabled.

Given that:

• 5432 works over both public and private endpoint
• 6432 works over public endpoint but not private endpoint
• VNET has no NSG or custom firewall

the most likely causes are:

1. PgBouncer not fully enabled or misconfigured
   • In the Azure portal, open the flexible server → Server parameters.
   • Confirm pgbouncer.enabled is set to true and saved.
   • After enabling, verify PgBouncer parameters (for example pgbouncer.default_pool_size, pgbouncer.max_client_conn, pgbouncer.pool_mode) are visible; if they are not, PgBouncer is not actually enabled.
   • From a VM in the same VNET/subnet as the private endpoint, test:

          psql "host=<server-name>.postgres.database.azure.com port=6432 dbname=postgres user=<user> password=<pwd> sslmode=require"
     

     This confirms whether 6432 is reachable over the private endpoint at all.
2. Client-side or path firewall allowing 5432 but not 6432
   • Even if the VNET has no NSG, there can still be:
     • Local OS firewall on the client
     • Corporate firewall / VPN / proxy rules
   • Ensure outbound TCP 6432 is allowed from the client to the VNET/private endpoint. The platform guidance explicitly calls out needing outbound 5432 open; the same requirement applies to 6432 when using PgBouncer.
3. Incorrect hostname or endpoint when switching to 6432
   • PgBouncer uses the same host name as the PostgreSQL server; only the port changes to 6432.
   • When using a private endpoint, the private DNS name for <server-name>.postgres.database.azure.com must resolve to the private IP. Confirm that the client resolving to the private IP is using that same FQDN when testing port 6432.
4. PgBouncer-side limits or errors
   • If 6432 is reachable but connections are dropped, check PgBouncer logs:
     • Enable Diagnostic Settings for the server and send logs to Log Analytics.
     • Query PGSQLPgBouncer (resource-specific schema) or AzureDiagnostics with Category == "PostgreSQLFlexPGBouncer" to see authentication failures, pool exhaustion, or other errors.
   • Optionally, configure pgbouncer.stats_users and connect to the internal pgbouncer database on port 6432 from a VM in the VNET to run SHOW POOLS, SHOW DATABASES, and SHOW STATS to verify PgBouncer is accepting connections and not rejecting them due to limits.
5. General connectivity validation
   • Use a simple TCP test (for example psql as above) from a VM in the same VNET/subnet as the private endpoint to distinguish between:
     • Network-level failure to reach 6432 over the private endpoint
     • Successful TCP connection but PostgreSQL/PgBouncer authentication or configuration issues

If 5432 works via the private endpoint from the same client and 6432 fails even with a direct psql test using the same FQDN and credentials, and PgBouncer is confirmed enabled, the next step is to inspect PgBouncer logs via Azure Monitor as above to identify whether PgBouncer is rejecting or not seeing the connection attempts.

---

References:

• PgBouncer in Azure Database for PostgreSQL
• Connection pooling strategy for Azure Database for PostgreSQL using PgBouncer
• Firewall rules in Azure Database for PostgreSQL
• Troubleshoot connection issues to Azure Database for PostgreSQL