DbInit

Short on purpose. detached borrows a second connection while the caller still holds its first, so one thread can hold two, and a full pool can deadlock on itself; the timeout is the only thing that turns that into an error. HikariCP's own 30 seconds reads as a hang to whoever is waiting on the request, and a request that cannot get a connection in 5 seconds is better answered with a 500 than left open.

Run on every connection the pool creates, not once on a borrowed one (DESIGN §8.7).

This is where search_path, application_name and statement timeouts belong. Without it an application that works in a non-public schema silently splits in two: its own connections see one schema and eezo's see another, which shows up as a migration that appears not to have run.

Small on purpose. HikariCP's sizing rule is connections = cores * 2 + spindles, because Postgres does its work on CPU and disk, and connections beyond what those can serve only queue inside the database instead of in the pool, where queueing is cheaper. Virtual threads make requests cheap, not connections: thousands of requests waiting briefly on a small saturated pool is the intended shape, not a sign the pool is too small.

Overridable, so a test or a second environment can point elsewhere without touching boot.