writing7 min read
Postgres pooling in 2026
A pragmatic survey of where pooling lives now — in the driver, in a sidecar, in the cloud — and which one to reach for first.
#postgres#infrastructure
Pooling used to be a single decision. You ran PgBouncer or you did not. In 2026 the decision tree has grown teeth, mostly because serverless runtimes broke the assumption that a process lives long enough to amortize a connection.
Three places pooling can live
- In the application — fine on a long-lived server, catastrophic in a Lambda.
- In a sidecar (PgBouncer, pgcat) — the workhorse answer, still the right call for most teams.
- In the cloud, at the edge of the database — Neon, Supavisor, RDS Proxy. Pay for the operator you do not have.
The fourth answer — HTTP drivers that wrap the Postgres wire protocol in a fetch call — is the one that has actually changed the landscape. If your runtime cannot hold a TCP connection, an HTTP driver lets you pretend you have a database without lying to yourself about pooling.