Knex connection pool limits: when does raising max stop helping?

Knex delegates connection pooling to tarn.js, with documented defaults of min 2 and max 10 connections per instance. Once the pool is exhausted, further queries queue waiting for a free connection, and transactions hold a dedicated connection for their entire lifetime.

My goal is to decide whether a perceived throughput bottleneck should be addressed by increasing pool max, or whether that just shifts the problem. Knex exposes pool introspection such as numUsed, numFree, and numPendingAcquires, so pending acquires can be measured before changing any settings. But pool metrics only show client-side queuing; they say nothing about slow SQL, missing indexes, or lock contention inside the database.

There is also a per-instance wrinkle: pool settings apply per Knex instance, so multiple instances against one database multiply total connections and can hit server-side limits such as PostgreSQL max_connections.

Assuming a recent Knex version (defaults may differ across majors):

• What threshold of pending acquires justifies raising pool max versus investigating query duration first?
• How should pool max be sized relative to the database's own connection limit when several Knex instances share one server?
• Is a long-held transaction visible in pool metrics distinctly enough to distinguish it from ordinary pool saturation?