PgBouncer Best Practices in Azure Database for PostgreSQL – Part 1

Shashikant_Shakya​ - 

Thanks for the great post—very useful for Azure Database for PostgreSQL users. I have a question about applying the default_pool_size guidance in a more typical Azure deployment.

In our environment, we run Azure Database for PostgreSQL and evaluating how to configure PgBouncer , hosting 10+ databases on a single server. There is a strict 1:1 mapping between database and role, resulting in roughly 10 (database, user) pools.

The challenge is that workloads are not uniform: a few databases are highly transactional with high concurrency, while others are low‑traffic configuration/reference databases.

Given this, using the formula mentioned in the post:

default_pool_size = max_concurrent_ops / number_of_pools

seems to assume evenly distributed load across pools, which doesn’t reflect real‑world Azure workloads. Since default_pool_size applies uniformly to all (db, user) pools and cannot be tuned per pool in Azure PgBouncer, how should this calculation be interpreted for such mixed‑workload scenarios?

Specifically:

• How do you recommend sizing default_pool_size when only a subset of databases requires high concurrency?
• Is the expected Azure‑recommended approach to rely more on max_db_connections, reserve pools, or even multiple PgBouncer deployments to handle uneven workloads?

Any Azure‑specific guidance or best practices on adapting this formula would be greatly appreciated.