TL;DR: Something is holding connections and not giving them back, or the pool is just too small. Use one shared `PrismaClient` instance, set `connection_limit` to match your database, raise `pool_timeout` for slow cold starts, and put serverless traffic behind a pooler like PgBouncer or Supavisor.

```text
Timed out fetching a new connection from the connection pool. (Current connection pool timeout: 10, connection limit: 5)
```

## Steps

1. Make sure you create exactly one client and reuse it:
   ```ts
   // lib/prisma.ts
   import { PrismaClient } from '@prisma/client'
   const globalForPrisma = globalThis as unknown as { prisma?: PrismaClient }
   export const prisma = globalForPrisma.prisma ?? new PrismaClient()
   if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma
   ```
   Expected: connection count on the database stops climbing with every request.

2. Size the pool in the connection string:
   ```
   postgresql://YOUR_HOST:5432/mydb?connection_limit=10&pool_timeout=20
   ```
   Expected: `pool_timeout=20` gives slow queries twice as long to get a connection before P2024 fires.

3. Serverless (Vercel, Lambda): point DATABASE_URL at your pooler in transaction mode with `?pgbouncer=true`, and keep a direct URL for migrations.
   Expected: P2024 under burst traffic drops sharply because the pooler multiplexes.

4. Find the leak: log `prisma.$queryRaw` connection counts or watch `pg_stat_activity` during the failure window.
   Expected: you see connections stuck in `idle in transaction`, which means a transaction was opened and never committed or rolled back.

## When to use
- The exact code is P2024, intermittent, worse under load or cold starts
- Connection count on the database climbs until queries start timing out

## When not to use
- P1001: nothing connects at all, the server is unreachable
- Every query is slow: that is a query performance problem, not pool exhaustion

## Compatibility
Prisma Client 4.x through 6.x. PostgreSQL and MySQL. Supabase, Neon, RDS.

### Variant phrasing: P2024 only during `next build` / prerender
Build-time data fetching opens many parallel connections. Raising `pool_timeout` for the build environment is the documented quick fix.

### Variant phrasing: P2024 with `connection_limit=1`
A limit of 1 serializes everything; any concurrent request waits. Raise it to at least your framework's concurrency.

## Why it happens
Prisma keeps a pool of database connections capped at `connection_limit`. Each query borrows one and returns it when done. If clients multiply (one per request), transactions leak, or the limit is smaller than your concurrency, new queries wait longer than `pool_timeout` and Prisma throws P2024.

## Edge cases
- Long-running transactions hold a connection for their whole life; keep transactions short.
- `connection_limit` counts per client instance, so two instances double your real connections.
- Statement timeouts on the database side surface as different errors; P2024 is specifically the pool wait expiring.