PgBouncer trades some Postgres features for lighter connections

The workload

A serverless function or highly concurrent application can open far more simultaneous connections to Postgres than its connection limit allows, since each Postgres connection is a separate backend process. PgBouncer describes itself, verified, as a 'lightweight connection pooler for PostgreSQL': a small proxy between application and database, holding a smaller pool of real connections and handing them to clients as needed. Adopting it means running an additional process — many managed Postgres providers now run one automatically — and choosing a pooling mode, a configuration decision with real behavioral consequences, not a checkbox.

What the documents show

PgBouncer's features documentation states, verified, that it supports three pooling modes of increasing strictness: session pooling, which assigns a server connection for a client's whole session and 'supports all PostgreSQL features'; transaction pooling, which assigns a connection only for the duration of one transaction and, in the document's own words, 'breaks a few session-based features of PostgreSQL'; and statement pooling, the most restrictive, which disallows multi-statement transactions. The same page lists casualties of transaction pooling, including session-level SET and RESET, LISTEN, session-level advisory locks, and WITH HOLD cursors — features that behave unpredictably because the underlying connection can change between statements. The documentation also states, verified, PgBouncer's own low memory requirement, '2 kB per connection by default,' the reason it can hold far more client connections open than Postgres could accept directly.

The operating cost

PgBouncer itself is free, open-source software; there is no license fee documented on its own site. The operating cost is the compute needed to run the pooler process, or, on managed platforms that bundle it, whatever that platform's own pricing page states for the tier in question, which sits outside PgBouncer's own documentation, plus the engineering time to identify which application code paths rely on session-level features that transaction pooling would break. Neither page states a connection-limit number that applies across every managed database, and that number varies by provider and plan, so none is asserted here.

The stop condition

The documentation does not name a point at which pooling-mode selection is finished. This is an editorial stop condition: transaction pooling is appropriate once the application has been audited against the features page's own incompatibility list and found not to depend on it; where advisory locks, cross-request prepared statements, or LISTEN/NOTIFY are load-bearing, session pooling — at its higher per-connection cost — is the documented fallback rather than working around the restriction.

• Does any code path rely on a feature the features page lists as broken under transaction pooling?
• What is this specific managed provider's actual connection ceiling, checked on its own pricing or limits page rather than assumed?
• Has the pooling mode been tested under the application's real concurrency, not just its idle state?

PgBouncer's own documentation is specific about what each pooling mode gives up, which turns a debugging mystery — a query behaving differently under load — into a known, named trade-off a founder can choose deliberately instead of discovering by accident.