pgBouncer.

Where pgBouncer fits on a long engagement.

Postgres allocates a process per connection, which makes connections expensive and finite. An application scaled to forty instances, each holding a pool of twenty, wants eight hundred connections from a database configured for a hundred. A pooler is not an optimisation at that point; it is what makes the architecture possible.

Pooling mode is the detail that breaks applications. Transaction pooling gives the best reuse and forbids session-level features — prepared statements, advisory locks, session variables, LISTEN/NOTIFY — because a client does not keep the same server connection between transactions. Applications using those silently misbehave rather than failing clearly.

What an assigned team does with pgBouncer.

The pooler becomes a critical path component the moment it is introduced. If it is down, the database is unreachable regardless of its own health, so it needs the same availability treatment as the database itself.

Sizing and monitoring it properly is part of the data layer rather than an afterthought, assigned under managed data services.

What we use pgBouncer for.

• Scaling application instances past the connection limit Many clients multiplexed onto few server connections.
• Pooling mode matched to the application Transaction mode only where no session-level features are relied on.
• The pooler treated as critical infrastructure Monitored and made redundant, because it sits in front of everything.

How pgBouncer capacity is assigned.

Connection management work sits inside data capacity, introduced before instance count exhausts the database rather than after an outage.