"Timeout acquiring a connection" under burst load: should pool.min be 0 or positive in Knex?

Under burst load my Knex queries intermittently reject with TimeoutError: Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call? I have confirmed I am passing trx correctly inside transactions, so the remaining suspect is pool sizing via tarn.js.

The trade-off I cannot resolve: with pool.min: 0, every cold start must create a connection, and under a sudden burst those creations can exceed createTimeoutMillis or serialize badly. With a positive min, idle connections stay open indefinitely, and with several app instances against a hosted Postgres with a low max_connections, the idle connections alone can exhaust server capacity. I have also read that connections killed by the database (e.g. MySQL wait_timeout) should be validated on checkout and replaced, but that this behavior is version-sensitive.

Assume Knex 2.x/3.x with tarn-backed pooling against Postgres.

1. Is there a documented or recommended heuristic for choosing pool.min relative to instance count and database max_connections?
2. Does tarn's validation-on-checkout reliably protect a positive min pool from handing out connections the server already killed, in current Knex versions?
3. Which pool events or metrics should I log to distinguish acquisition timeouts caused by cold-start creation from genuine pool exhaustion?