Prisma ORMRunbook 0/4 done
P2024

Prisma ORM Error P2024: Connection pool timeout

Critical↻ Retryable · exponential backoffHTTP 503 Service UnavailableDatabase
TL;DR · 10-second read

All connections in Prisma's pool were busy for longer than pool_timeout (default 10s). Reuse one PrismaClient, size connection_limit for your platform, and use a pooler for serverless.

Identify: does your log match?

What you see · exact log / response
PrismaClientKnownRequestError:
Invalid `prisma.order.findMany()` invocation:

Timed out fetching a new connection from the connection pool. More info: http://pris.ly/d/connection-pool (Current connection pool timeout: 10, connection limit: 5)
  code: 'P2024',
  meta: { modelName: 'Order', connection_limit: 5, timeout: 10 }
  1. High

    Many PrismaClient instances

    Instantiating PrismaClient per request or on every hot reload creates a new pool each time. Connections pile up while each pool stays small.

  2. High

    Pool too small for concurrency

    Default connection_limit is num_cpus × 2 + 1; in a 1-vCPU container that is 3. Promise.all over 50 queries queues behind 3 connections.

  3. Medium

    Slow queries hold connections

    A missing index or long interactive $transaction keeps connections checked out, starving other requests.

Fix

Share one PrismaClient across hot reloads

✕ Broken · Next.js
// lib/db.ts
import { PrismaClient } from '@prisma/client';
export const prisma = new PrismaClient();
✓ Fixed · Next.js
// lib/db.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;

Caching the client on globalThis survives Next.js dev reloads, so you keep one pool instead of one per reload.

Verify: reproduce it on purpose

Reproduce locally · node
$ DATABASE_URL="$DATABASE_URL?connection_limit=1&pool_timeout=2" node -e "const {PrismaClient}=require('@prisma/client');const p=new PrismaClient();Promise.all([...Array(5)].map(()=>p.\$queryRaw\`SELECT pg_sleep(3)\`)).catch(e=>console.log(e.code))"

Run it against a dev environment to trigger P2024 on purpose and test your error handler.

Prevent

  • Never call new PrismaClient() inside a request handler.
  • Batch with Promise.all in chunks no larger than connection_limit.
  • Enable Prisma metrics to watch prisma_pool_connections_busy.

FAQ

What is the default Prisma connection_limit?

num_physical_cpus × 2 + 1. Set it explicitly in the connection string so behavior does not change across machines.

Should I set pool_timeout=0?

0 disables the timeout, so requests wait forever instead of failing. Prefer a finite value and fix the underlying contention.

Is P2024 the same as Postgres "too many clients"?

No. P2024 is Prisma's client-side pool; Postgres 53300 means the server itself rejected the connection. Too many Prisma pools can cause both.

Related errors

Last verified 2026-10-22 · Source: Prisma error reference P1000–P6010 · Official docs ↗ · ~8,100 searches/mo