Generic Best Practices for HikariCP with Azure Database for PostgreSQL

Thank you for the feedback and for sharing the configuration.

When PgBouncer is used together with HikariCP, it is important to avoid configuring two very large pooling layers. With maximumPoolSize=300 and minimumPoolSize=100, each application instance can maintain a substantial number of client connections to PgBouncer. If multiple application pods or instances use the same settings, the total client count can grow quickly.

The PgBouncer message client disconnect while server was not ready generally indicates that the client disconnected while PgBouncer was still waiting for or preparing a PostgreSQL backend connection. By itself, it does not confirm a PostgreSQL server failure. It can occur when the application timeout is reached first, a request is cancelled, an instance is shutting down, or PgBouncer has clients waiting for available server connections.

I would recommend starting with a significantly smaller HikariCP pool and sizing it from measured application concurrency rather than the database’s maximum connection capacity. As an initial test, you could reduce maximumPoolSize to a conservative range such as 20 to 50 per application instance and set minimumIdle much lower, for example 0 to 10. These are starting points only and should be validated through load testing and production metrics.

Also, please calculate the aggregate pool across all instances:

maximumPoolSize × application instances × data sources

On the PgBouncer side, verify pool_mode, default_pool_size, max_client_conn, and query_wait_timeout. Azure’s built-in PgBouncer uses transaction pooling by default. Please also enable PgBouncer diagnostics and correlate the event timestamps with client_connections_waiting, active and idle server connections, total pooled connections, application connection-timeout errors, pod restarts, and long-running transactions.

If client_connections_waiting increases during the events, this would indicate that clients are waiting for PostgreSQL backend capacity. If it remains at zero, the investigation should focus more on client timeout, cancellation, instance lifecycle, or transient connectivity.

A possible test configuration could be:

spring.datasource.hikari.maximumPoolSize=30

spring.datasource.hikari.minimumIdle=5

spring.datasource.hikari.connectionTimeout=30000

The timeout value should be aligned with the application’s latency requirements and PgBouncer’s waiting behavior. I would avoid increasing pool sizes or timeouts before confirming where the wait occurs, as that can hide saturation and increase connection pressure.

Azure references:

• PgBouncer in Azure Database for PostgreSQL Flexible Server
• Connection pooling strategy using PgBouncer
• Monitoring PgBouncer metrics and logs