Intermittent 'too many clients' errors on Scalingo managed PgBouncer

Diagnose intermittent PostgreSQL connection pool exhaustion on Scalingo’s managed PgBouncer add-on when applications report “sorry, too many clients already” under variable load.

PgBouncer defaults to transaction pooling mode and enforces max_client_conn and pool_size limits tied to the database plan. Framework pools such as HikariCP or node-pool can hold slots past transaction boundaries when transactions remain open, while Scalingo exposes aggregated connection metrics but not per-application queue depth or PgBouncer logs. The contributing cause—application pool sizing, long-running transactions, or platform limit saturation—is not isolated.

Does Scalingo permit independent adjustment of max_client_conn or pool_size outside plan limits? Can dashboard metrics and application logs distinguish PgBouncer queue waits from backend saturation? Is server_reset_query configurable on managed PgBouncer, and does the default DISCARD ALL behavior add measurable latency in transaction mode?