Knex.js and Driver Connection Pool Interaction Under High Concurrency

Integration Boundary: Knex.js and the Underlying Driver Connection Pool

The goal is to determine whether Knex.js should provide a built‑in retry or back‑off mechanism for connection‑acquire failures that appear only under concurrent request loads.

Knex.js does not manage connections itself; it relies on the pool implementation of the selected driver (pg, mysql2, etc.). Under high concurrency, the pool’s acquire queue can grow, causing latency spikes even when individual queries execute quickly. Because the pool configuration (max connections, acquire timeout) is driver‑specific and Knex only exposes a generic pool option, applications must implement retry logic themselves, leading to inconsistent handling across projects.

Given the version‑dependent abstraction of pool settings (pre‑0.95 vs. post‑0.95) and the lack of a unified retry policy, the unresolved decision is whether Knex should expose a configurable retry/back‑off layer that works uniformly across drivers.

Should Knex provide a configurable retry mechanism for connection acquire failures?

What default back‑off strategy would be appropriate without overriding driver‑specific pool behavior?

How would exposing such a feature interact with existing pool options like max and acquireTimeoutMillis?