Connection pooling reuses a bounded set of PostgreSQL connections while allowing more application requests to wait briefly for service. This trades some application latency for database health. section 6.3
Avoid opening every connection the application requests:
- Insert a pooler such as PgBouncer between the application and PostgreSQL. section 6.3
- Accept many application-side connections, but allow only a configured number through to PostgreSQL; queue the remainder. section 6.3
- Monitor pg_stat_activity for LWLock waits and compare requested connections with actual active database work. section 6.3
Why thousands of connections can hurt
An application with 5,000 connections may run only 15–30 active database tasks. A 2,000-client pgbench test produced 352.1 TPS and 5,535 ms average latency, while 250 clients produced 635.7 TPS and 393 ms latency. section 6.3








