Prisma 5.0 poolTimeout Defaults for Bursty Serverless Workloads

Prisma 5.0 introduced the poolTimeout datasource parameter to control how long a query waits for an available connection before throwing ConnectionTimedOut. The default of 30000ms is documented, but no guidance exists for choosing values that suit applications with highly variable or bursty request patterns, especially in serverless environments where cold starts and connection reuse behavior differ from long-running processes.

In serverless deployments, each function invocation may instantiate a new PrismaClient unless explicitly cached, causing rapid connection churn. A low poolTimeout surfaces exhaustion quickly but may reject legitimate requests during traffic spikes. A high value queues requests longer, potentially masking connection leaks or exhausting database-side connection limits before the application reacts.

The interaction between poolTimeout, connection_limit (default 10 for PostgreSQL/MySQL), and provider-specific connection semantics remains undefined for workloads that shift between idle and high concurrency within seconds.

What poolTimeout values have proven effective for bursty serverless workloads with constrained connection_limit? How does the parameter behave when PrismaClient instances are created per-invocation versus reused across warm starts? Are there observable pool-usage metrics exposed by Prisma Client that can inform tuning without relying on trial-and-error load testing?