configuring-serverless-clients

Connection pool exhaustion occurs when each serverless invocation creates its own PrismaClient instance. Solve this by implementing a global singleton pattern in lib/prisma.ts that reuses a single PrismaClient across invocations, combined with setting connection_limit=1 in your DATABASE_URL to prevent per-instance pool overflow.

Yes. Configure PrismaClient as a global singleton, set connection_limit=1 in DATABASE_URL, and avoid instantiating new PrismaClient() within handler functions. This pattern works across Next.js App Router, Pages Router, AWS Lambda, and Vercel, eliminating P1017 connection pool errors in multi-instance deployments.

Combine a global singleton PrismaClient with connection_limit=1 in DATABASE_URL and add pool_timeout settings. For very high concurrency (10+ concurrent requests), route connections through PgBouncer to manage connection pooling at the database proxy layer rather than within each function instance.

PgBouncer is optional. A global singleton with connection_limit=1 handles most serverless scenarios. Use PgBouncer only when you need to support very high concurrency across many simultaneous invocations and want centralized connection pooling beyond per-instance limits.

Test your configuration by simulating 10+ concurrent function invocations and verifying that all requests successfully reuse the singleton PrismaClient without connection exhaustion. Monitor for P1017 errors and confirm that connection_limit=1 and pool_timeout settings prevent pool starvation under load.