Master connection pooling vocabulary: PgBouncer, pool size, pool exhaustion, max_connections, pool modes, and connection saturation.
0 / 5 completed
1 / 5
What is PgBouncer and why is it used with PostgreSQL?
PostgreSQL's connection model is expensive: each connection forks a new backend process. With hundreds of app server threads, direct connections exhaust OS resources. PgBouncer pools connections so 500 app threads might share 20 actual DB connections.
2 / 5
What does 'the connection pool is saturated' mean?
Pool saturation means demand for connections exceeds the pool size. Requests queue waiting for a free connection. If the queue grows unchecked, requests time out. The fix may be increasing pool size, reducing connection hold time, or scaling the database.
3 / 5
What is the PostgreSQL `max_connections` parameter?
max_connections defines how many simultaneous client connections PostgreSQL will accept. Because each connection consumes shared memory and a backend process, setting it too high can cause memory pressure. PgBouncer allows many app connections to share a small max_connections budget.
4 / 5
What is PgBouncer's 'transaction mode' pool mode?
Transaction mode is the most efficient PgBouncer mode: a server connection is borrowed from the pool for one transaction and immediately returned. This allows 1000 app connections to share 10 server connections efficiently, but prohibits session-level state (SET, prepared statements, advisory locks).
5 / 5
A team says 'we increased the connection pool size to reduce latency'. What trade-off does this involve?
Pool size tuning is a balance: too small causes queuing and latency; too large causes PostgreSQL memory pressure and potential instability. The optimal pool size depends on the number of CPU cores, workload type, and available memory — not simply 'bigger is better'.