Prisma Client connection pool: configuring idle timeout and max connection age for long-running transactions

The Prisma Client connection pool defaults to a fixed number of connections (commonly 10), and the documented timeout option governs query execution rather than the lifecycle of pooled connections. In a service handling bursts of concurrent queries alongside occasional long-running transactions, connections can remain checked out far longer than expected, and the pool appears to have no built-in idle timeout or maximum connection age to reclaim them.

The goal is to keep the pool healthy under sustained concurrency without manual restarts: abandoned or stalled connections should eventually be released back to the pool (or to the database) instead of accumulating until new queries begin failing. Assume Prisma 5.x with PostgreSQL, though version-specific differences are a concern and should be flagged if behavior diverges.

The uncertainty is whether this is even configurable today. The pool size is set at initialization and seemingly cannot change at runtime, and no documented setting appears to cover idle eviction or connection TTL.

Is there a supported way in current Prisma versions to bound how long a pooled connection may stay idle or checked out? If not, is the intended boundary that connection lifetime must be enforced at the database or infrastructure layer instead? And does the answer differ between PostgreSQL and MySQL drivers?