Databases
Connection pooling: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the mechanism stick when you need it during an incident.
Reconstruct the unit’s spine from memory — why backends are heavyweight, what transaction mode trades away, how to size both pool layers, why exhaustion is hold-time, and how idle-in-transaction harms beyond the pool.
- 01Why is a Postgres connection expensive, and what are the two pool layers that absorb that cost?
- 02What does PgBouncer transaction mode buy, what does it break, and what is the safe substitute for each break?
- 03How do you size the two pool layers, and why is pool_size NOT the client count?
- 04Why is pool exhaustion almost always a hold-time problem, and why does raising pool_size usually fail?
- 05Beyond occupying a pool slot, what else does an idle-in-transaction backend harm, and why?
- 06When do you reach past PgBouncer, and what is the serverless connection-storm fix?
If you could reconstruct each answer from memory you hold the unit’s spine: backends are heavyweight processes, so two pool layers exist — a client pool per worker to kill per-request setup, and a server pooler to multiplex thousands of clients onto a backend count sized to the CPU via (cores × 2) + spindles. Transaction mode is the multiplexing default and trades connect-time session state, each break with an exact substitute, with PgBouncer 1.21+ restoring prepared statements. Exhaustion is hold-time, not size; idle-in-transaction also pins an MVCC snapshot and blocks VACUUM; and you only outgrow PgBouncer when you have measured its single-thread ceiling or face serverless/multi-tenant scale.