Connections

An application boundary contains one queued caller, a rejected caller and a holder; only the holder connects to the single pool backend.

A pool shares a few Postgres connections among many requests

A connection pool lets many application requests borrow a smaller number of PostgreSQL sessions over time. Reuse amortizes connection setup and limits simultaneous leases, but does not make an overloaded database faster by itself. The pool creates another queue whose capacity, waiting time, and cancellation behavior belong to the request budget. Treat that queue as part of the service, not as an invisible implementation detail. ...

Three independent pool boxes each hold two retained-connection circles and one overflow circle: three times two plus one equals nine physical connections. Source pool fixture, not rerun.

Connection caps guard a shared database

A connection cap limits one owner’s demand; it does not automatically cap every application sharing a database. The useful budget is the sum of physical connections that can reach each backend, including idle pooled connections. Begin with the backend’s usable slots, then allocate them across all callers and deployment states. ...