Timed out fetching a new connection from the connection pool.

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.

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:

   // 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.

1. 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.

1. 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.

1. 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.