Practical Notes on Postgres Connection Pooling

By Owen Gallagher · May 13, 2026 · Data

Postgres connections are heavy - each backend carries megabytes of memory and a full process - so every scaled-out installation grows a pooler, and every pooler grows a dialect. Session pooling is nearly transparent; transaction pooling is fast and unforgiving, quietly breaking session features like LISTEN, advisory locks and SET.

Most pooler incidents trace to respect: sessions checked out and never returned, cursors held across sleeps, and schema changes that iterate every table while holding one checkout. Transaction mode makes those bugs louder instantly, which shortens the debugging at the cost of breaking the code that committed them.

Size the pool on the database side, not the client side. Servers slow down above an active-connections ceiling roughly proportional to cores times some small constant, and a pooler exists to enforce that ceiling kindly, before the kernel does it brutally.