writing7 min read
Postgres pooling in 2026
A pragmatic survey of where pooling lives now, whether in the driver, a sidecar, or 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.