Connection Pooling

Opening a database connection is expensive — TCP, TLS, authentication, and a process or buffer allocated server-side — and databases only handle so many at once (Postgres defaults to about a hundred). A pool pays that setup cost once per connection, then lends connections to requests and takes them back. The pool is also a queue: when all connections are busy, requests wait their turn instead of stampeding the database.

Any server that talks to a database wants one — it is the default in every serious driver and ORM. The counter-intuitive case is sizing: throughput usually peaks at a small pool (roughly CPU cores × 2 for the database, not hundreds), because the database can only truly work on a few queries simultaneously; more connections just add contention.

Serverless and heavily-replicated deployments need an external pooler — PgBouncer or a managed equivalent — because a thousand short-lived function instances each holding five connections is five thousand connections the database cannot host.

Pools add failure modes of their own: a leaked connection (taken, never returned) slowly starves the pool; a stale one dies mid-query after a network blip; and a pool sized bigger than the database's limit just moves the crash. Transaction-level pooling (PgBouncer's efficient mode) also breaks session state like prepared statements — a real compatibility cost.

Size the pool deliberately (start near cores × 2 on the database side, divided across app instances), set acquisition and idle timeouts, and always release in a finally — or better, use helpers that scope the connection for you. Add health checks to evict dead connections, and monitor pool wait time: rising waits mean the bottleneck is the database, and a bigger pool will not fix it.