liveBook · Manning

Connection pooling

As explained in PostgreSQL Mistakes and How to Avoid Them

Connection pooling is a technique that reuses a bounded set of database connections to serve a larger number of client requests.

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

How PostgreSQL Mistakes and How to Avoid Them covers it

How deep it goes
Explains queueing, pooler behavior, monitoring signals, and process-level performance costs.
Examples
Uses PgBouncer, pg_stat_activity, a 5,000-connection observation, and pgbench client-count benchmarks.
What you can do after
Operate/configure application connection limits and diagnose excessive concurrency with PostgreSQL monitoring.
How it connects
Connects PgBouncer with pg_stat_activity, concurrency, process overhead, and process thrashing.

Also explained in

Compare how 9 books explain connection pooling →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of PostgreSQL Mistakes and How to Avoid Them. The section links point to the parts of the book it draws on.