Pool

Connections for one database, owned by Database and by nothing else. DESIGN §8.7.

A real pool, because opening a Postgres connection costs a TCP handshake, authentication and a backend process, and a request that paid that on every read would spend more time connecting than querying. The pool is HikariCP rather than one written here: a pool's bugs are stalls under load, and HikariCP's are already found.

The size is fixed, minimumIdle equal to maximumPoolSize, because a pool that shrinks when idle pays the connect cost again on the first request after a quiet spell, which is exactly the request somebody is watching. The acquire timeout is short because detached borrows a second connection while the caller's transaction still holds its first: one thread can hold two connections, so a full pool can deadlock, and a timeout is what turns that into an error instead of a hang.

The pool starts empty (initializationFailTimeout negative) so that building one never waits on the network: an application whose database is down still boots, and fails the first request that needs Postgres, after the acquire timeout, rather than failing in main. HikariCP keeps retrying in the background, so the database coming back needs no restart.

init runs on every physical connection the pool opens, not once on a borrowed one. That distinction is what makes per suite search_path isolation work: search_path is per connection, so a suite that set it on one borrowed connection would silently read the wrong schema through the next. Production wants the same hook for application_name and statement timeouts.