Why I put PgBouncer in front of Postgres before I needed to

Postgres handles direct connections fine at small scale, and that's exactly why connection pooling is easy to skip — nothing forces the decision until a spike in traffic or a fleet of short-lived backend instances starts opening more connections than the database was configured to hold. Each Postgres connection reserves its own backend process, and that process has real memory overhead regardless of whether the connection is actively doing anything. In a setup with NestJS, Redis, and multiple services in the same Docker Compose stack, connections add up fast even in development, let alone production. I put PgBouncer in front of Postgres specifically to avoid discovering this the hard way. Configured in transaction mode, PgBouncer holds a small pool of actual Postgres connections open and hands them out to clients only for the duration of a single transaction, then returns them to the pool immediately after. From the application's point of view nothing changes — it still connects the same way — but the database only ever sees a fraction of the concurrent connections it would otherwise. The tradeoff worth knowing about is that transaction mode doesn't support session-level features like prepared statements or advisory locks tied to a session, since the underlying connection can be handed to a different client between transactions. That ruled out a couple of Postgres features I'd used casually before, but for a typical NestJS request-response cycle where each transaction is self-contained, it wasn't a real limitation. The bigger win was operational: connection exhaustion under load became a non-issue I didn't have to think about, instead of a failure mode I'd eventually hit and have to diagnose live.