Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
blader avatar

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)
At a glance

prisma-connection-pool-exhaustion capabilities & compatibility

Capabilities
debugging · database tuning · connection pooling
Works with
supabase · postgres · vercel · aws
Use cases
debugging · database
From the docs

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).
SKILL.md
The recommended solution is to use a connection pooler like PgBouncer or Prisma Accelerate, which sits between your serverless functions and the database.
SKILL.md
`connection_limit=1`: One connection per serverless instance
SKILL.md
npx skills add https://github.com/blader/claudeception --skill prisma-connection-pool-exhaustion

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
repo stars2.4k
Last updatedFebruary 21, 2026
Repositoryblader/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

SKILL.mdMarkdownGitHub ↗

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 dev but 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 pooling

For Prisma Accelerate:

npx prisma generate --accelerate

Step 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 = prisma

Step 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 = prisma

Step 4: URL Parameters

Add these to your connection string:

?connection_limit=1&pool_timeout=20&connect_timeout=10
  • connection_limit=1: One connection per serverless instance
  • pool_timeout=20: Wait up to 20s for available connection
  • connect_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=1 is 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.

Debuggingbackenddevops

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.