Problem with PrismaClient()

Prisma is an ORM that lets you work with your database using familiar language constructs instead of raw SQL. In short, it acts as a middle layer that translates your function calls into SQL commands the database understands.

YOU → ORM → DB

// Plain SQL 
SELECT * FROM users WHERE id = 1; 

// Prisma ORM
user = prisma.user.find_unique(where={"id": 1}) 

A common setup

1. Import the Prisma Client

2. Create a client instance

3. Export and reuse it across the project

import { PrismaClient } from "../generated/prisma"

const prisma = new PrismaClient()

export default prisma

This is idiomatic and works until development hot reloads get involved.

Why does this break in development

Next.js performs Hot Reloading in development, re-running modules whenever code changes. Each reload re-executes the file above, creating another Prisma Client instance. Every instance maintains its own connection pool. Over time, multiple instances can accumulate and exhaust the database’s connection limit, resulting in errors.

Note: new PrismaClient() does not eagerly connect to the database. It creates a client that opens connections lazily. The issue is not “many connections at once” at creation time, but “many client instances” persisting across reloads, each able to manage its own pool.

The fix: use a global singleton in dev

Persist the Prisma Client on the Node.js global object during development. Next.js module reloads won’t reset the global scope, so the same instance is reused between hot reloads. In production, where hot reloading doesn’t occur, you can instantiate normally.

import { PrismaClient } from "../generated/prisma"

const globalForPrisma = global as unknown as {
 prisma?: PrismaClient
}

const prisma = globalForPrisma.prisma ?? new PrismaClient()

if (process.env.NODE_ENV !== "production") {
 globalForPrisma.prisma = prisma
}

export default prisma

• Development: Reuses a single Prisma Client across hot reloads

• Production: Creates a fresh instance per process (no global caching)

Common mistakes

• Creating a new client in every request handler or function. Prefer importing a shared instance.

• Mixing multiple client versions or generators across reloads. Ensure a single source of truth for your client import.

• Assuming new PrismaClient() immediately connects. It’s lazy; the problem is instance count, not instant connections.

REVISE

• Hot reloads can create multiple Prisma Client instances in dev

• Each instance maintains its own pool, risking connection exhaustion

• Store the client on global in dev to keep a single instance

• Keep production behavior unchanged for simplicity and reliability