Part 3 · 1 chapters · ~8 min
Connection Poolers
Why poolers appear in every stack that grows, PgBouncer, PgCat and Supavisor for Postgres, ProxySQL for MySQL, RDS Proxy for serverless, and where the pooler sits (sidecar or central) for each runtime.
5
Poolers per runtime
| runtime | pooling inside | usually paired with |
|---|---|---|
| Node | pg Pool or driver pool per process | PgBouncer (transaction mode) once replicas multiply |
| Python / Django | persistent connections per worker (CONN_MAX_AGE), psycopg pool | PgBouncer: many Gunicorn workers × pods add up fast |
| Rails | ActiveRecord pool per process, sized to Puma threads | PgBouncer; Rails needs prepared statements off in older setups |
| Go | database/sql pool (SetMaxOpenConns) | often fine alone; PgBouncer at many replicas |
| Java | HikariCP | often fine alone (few JVMs); PgBouncer for many pods |
| serverless anything | none that survives between invocations | RDS Proxy, Neon pooler, or an HTTP data API |
| MySQL apps | driver pools | ProxySQL (pooling, read/write split, query rules) |
The rule from the Scaling course applies to every language: total server connections = processes × pool size × replicas, and the database's useful concurrency is a small multiple of its cores.