A high cl_waiting establishes that clients are waiting, not that the pool is undersized. Compare active server connections and query duration within the same database/user pool. Idle connections in another pool do not establish spare capacity for the waiting clients.
SHOW POOLS;
SHOW STATS;
SHOW DATABASES;Run these in the PgBouncer administration console, not a PostgreSQL application database. Match fields to the installed version’s administration reference and compare the same pool over time. Changes in waiting and throughput are more informative than one cl_waiting, sv_active or sv_idle reading.
A sizing example: what would doubling the pool change?
Four hypothetical database/user pools capped at 20 server connections already represent a simple total budget of 80. Add the budgets of multiple PgBouncer instances targeting the same PostgreSQL server. Treating default_pool_size as a global total can consume administrative and replication headroom. Compare pool limits with database/user limits in the configuration reference.
If waiting grows alongside long transactions or lock waits, inspect query and transaction scope first. If the database has headroom and short normal queries hit the pool cap, test a modest adjustment in staging and compare throughput and latency. More connections with unchanged throughput and greater database waits is not a useful fix.
Reload, reconnection and restart requirements differ by setting. Preserve previous values and verify waits and errors under the same workload. The numbers 20 and 80 are illustrative arithmetic, not observations or recommended sizes for this server.