
Prisma Connection Pool Exhaustion
- 2.4k repo stars
- Updated February 21, 2026
- blader/claudeception
prisma-connection-pool-exhaustion is a Claude Code skill that fixes Prisma 'too many connections' and P2024 pool-exhaustion errors in serverless environments.
About
This skill fixes Prisma connection pool exhaustion in serverless environments like Vercel, AWS Lambda, and Netlify. A developer uses it when they hit P2024 timeout or PostgreSQL 'too many connections' errors that appear only in production under load. It walks through connection poolers, per-instance connection limits, the singleton client pattern, and connection-string parameters.
- Fixes Prisma P2024 and 'too many connections' errors in serverless environments
- Recommends connection poolers (PgBouncer, Supabase pooler, Neon, Prisma Accelerate)
- Covers connection_limit, singleton pattern, and pool-timeout URL parameters
Prisma Connection Pool Exhaustion by the numbers
- Data as of Aug 5, 2026 (Skillselion catalog sync)
prisma-connection-pool-exhaustion capabilities & compatibility
- Capabilities
- debugging · database tuning · connection pooling
- Works with
- supabase · postgres · vercel · aws
- Use cases
- debugging · database
What prisma-connection-pool-exhaustion says it does
Serverless functions create a new Prisma client instance on each cold start. Each instance opens multiple database connections (default: 5 per instance).
The recommended solution is to use a connection pooler like PgBouncer or Prisma Accelerate, which sits between your serverless functions and the database.
`connection_limit=1`: One connection per serverless instance
npx skills add https://github.com/blader/claudeception --skill prisma-connection-pool-exhaustionAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| repo stars | ★ 2.4k |
|---|---|
| Last updated | February 21, 2026 |
| Repository | blader/claudeception ↗ |
What it does
Stop Prisma P2024 pool-exhaustion errors in serverless production by adding a connection pooler and per-instance limits.
Who is it for?
Serverless Prisma apps on Vercel, Lambda, or Netlify hitting connection limits under traffic spikes.
Skip if: PlanetScale (MySQL), which uses a different architecture and does not have this issue.
When should I use this skill?
Prisma throws P2024 'Timed out fetching a new connection' or PostgreSQL reports 'too many connections' in serverless production.
What you get
Database connections stay within limits under load and P2024 errors stop appearing in logs.
- A pooled connection string and Prisma client config that stays within DB connection limits
By the numbers
- 4-step solution
- default 5 connections per Prisma instance
- recommends connection_limit=1
Files
Prisma Connection Pool Exhaustion in Serverless
Problem
Serverless functions create a new Prisma client instance on each cold start. Each instance opens multiple database connections (default: 5 per instance). With many concurrent requests, this quickly exhausts the database's connection limit (often 20-100 for managed databases).
Context / Trigger Conditions
This skill applies when you see:
P2024: Timed out fetching a new connection from the connection pool- PostgreSQL:
FATAL: too many connections for role "username" - MySQL:
Too many connections - Works fine locally with
npm run devbut fails in production - Errors appear during traffic spikes, then resolve
- Database dashboard shows connections at or near limit
Environment indicators:
- Deploying to Vercel, AWS Lambda, Netlify Functions, or similar
- Using Prisma with PostgreSQL, MySQL, or another connection-based database
- Database is managed (PlanetScale, Supabase, Neon, RDS, etc.)
Solution
Step 1: Use Connection Pooling Service
The recommended solution is to use a connection pooler like PgBouncer or Prisma Accelerate, which sits between your serverless functions and the database.
For Supabase:
# .env
# Use the pooled connection string (port 6543, not 5432)
DATABASE_URL="postgresql://user:pass@db.xxx.supabase.co:6543/postgres?pgbouncer=true"For Neon:
# .env
DATABASE_URL="postgresql://user:pass@ep-xxx.us-east-2.aws.neon.tech/dbname?sslmode=require"
# Neon has built-in poolingFor Prisma Accelerate:
npx prisma generate --accelerateStep 2: Configure Prisma Connection Limits
In your schema.prisma:
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
// Limit connections per Prisma instance
relationMode = "prisma"
}In your connection URL or Prisma client:
// lib/prisma.ts
import { PrismaClient } from '@prisma/client'
const globalForPrisma = global as unknown as { prisma: PrismaClient }
export const prisma = globalForPrisma.prisma || new PrismaClient({
datasources: {
db: {
url: process.env.DATABASE_URL + '?connection_limit=1'
}
}
})
if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prismaStep 3: Singleton Pattern (Development)
Prevent hot-reload from creating new clients:
// lib/prisma.ts
import { PrismaClient } from '@prisma/client'
const globalForPrisma = globalThis as unknown as {
prisma: PrismaClient | undefined
}
export const prisma = globalForPrisma.prisma ?? new PrismaClient()
if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prismaStep 4: URL Parameters
Add these to your connection string:
?connection_limit=1&pool_timeout=20&connect_timeout=10connection_limit=1: One connection per serverless instancepool_timeout=20: Wait up to 20s for available connectionconnect_timeout=10: Fail fast if can't connect in 10s
Verification
After applying fixes:
1. Deploy to production 2. Run a load test: npx autocannon -c 100 -d 30 https://your-app.com/api/test 3. Check database dashboard—connections should stay within limits 4. No more P2024 errors in logs
Example
Before (error under load):
[ERROR] PrismaClientKnownRequestError:
Invalid `prisma.user.findMany()` invocation:
Timed out fetching a new connection from the connection pool.After (with connection pooling):
# Using Supabase pooler URL
DATABASE_URL="postgresql://...@db.xxx.supabase.co:6543/postgres?pgbouncer=true&connection_limit=1"Database connections stable at 10-15 even under heavy load.
Notes
- Different managed databases have different pooling solutions—check your provider's docs
- PlanetScale (MySQL) uses a different architecture and doesn't have this issue
connection_limit=1is aggressive; start there and increase if you see latency- The singleton pattern only helps in development; in production serverless, each
instance is isolated
- If using Prisma with Next.js API routes, each route invocation may be a separate
serverless function
- Consider Prisma Accelerate for built-in caching + pooling: https://www.prisma.io/accelerate
Related skills
FAQ
Why does Prisma exhaust connections in serverless but not locally?
Each serverless cold start creates a new Prisma client opening multiple connections, and concurrent requests quickly exceed the database limit.
What is the recommended fix?
Use a connection pooler like PgBouncer, the Supabase/Neon pooled endpoint, or Prisma Accelerate, and set connection_limit=1 per instance.