warn(prisma-client) Already 10 Prisma Clients are actively running.

[theprantadutta]

I am getting this warning in my console. Can someone explain why am I getting this warning.

warn(prisma-client) Already 10 Prisma Clients are actively running.

[nikolasburk]

Hey @prantadutta, the issue is likely that you are creating a lot of PrismaClient instances – each of which has its own DB connection pool. Prisma therefore prints a warning so that you can maybe dispose a few of these instances.

Without knowing more about your project, it's very difficult to help you with this but I can make a few assumptions and give some hints:

• maybe you're calling new PrismaClient() often in your code – instead you can try to call it only once and pass the resulting PrismaClient instance around in your application
• are you using some kind of hot-reloading mechanism?

It would be great if you could share a bit more info about your project 🙂

[theprantadutta]

@nikolasburk Thanks for answering. But I solved that by returning a new Promise function with resolve and reject callback. I am currently using nextjs and nextjs api with prisma client and I am creating a new instance of PrismaClient() in every api.ts file. So is there a way to create only one PrismaClient and use it in every api.ts file? Thanks in advance.

[sehmaschine]

I think you could add a file _base.js (for example) within your folder api, create the PrismaClient there and import it with your api routes.

[nikolasburk]

What @sehmaschine suggest would definitely work! Another approach would be to create a top-level lib folder (or similar) where you create the instance and import it everywhere else, like shown in this example.

[theprantadutta]

@sehmaschine @nikolasburk Thanks, that really helped. You guys are the best.

[juanzgc]

@nikolasburk I've attempted the example that you've included and I still see this warning appear. At times it has gotten up to 100 clients which then results in: FATAL: sorry, too many clients already

I've also attempted this with no luck Issue 1983
Mind you my testing has been done locally.

Any suggestions?

[sehmaschine]

I guess I have to put my "solution" into perspective. While using Next.js with a local dev setup, I'm running into this issue as well. I have to kill lots of prisma processes on a regular basis. Haven't tested if this also happens with a production setup.

I don't see a direct correlation between the number of imports (of the Prisma client) and the number of processes running. This seems to be arbitrary.

[masoudsaif]

Hello @prantadutta, try creating creating one prisma client and export it to the whole project, and you would still get the warning but it will exist only in development mode because next.js hard refresh just in case you don't want the warning in development mode check this link__

[glaucusec]

I tried the solutions marked here. but the vscode autocomplete is not working when I do that. It worked fine and shows the prisma methods and stuff on keystroke, but when i import it, it doesn't work. any ideas for the possible reason and remediation?

[toman92]

Hi @nikolasburk, I'm getting this warning too but only in a production environment. It isn't happening locally at all even with hot-reload. I have the Prisma client in a singleton and have added logging to the singleton to log every time a new instance is created. Only one instance has been created (as expected) but I'm still getting warn(prisma-client) There are already 10 instances of Prisma Client actively running. in my production logs. It doesn't seem to be causing issues (yet) but it's a bit concerning. It has only happened from upgrading from prisma 2.x to 3.x. I've noticed it happening on v3.0.1 up to the latest release v3.11.1. It didn't happen at all on v2.x so I'm wondering if it might be a bug? Has any one else noticed this behaviour or found what might be causing it? When I get a bit of time I'll try create a minimal repro and create an issue with any findings.

[janpio]

3.x is fundamentally different behind the scenes, so that might be the cause here. Best open a new issue and provide all the information you can come up with.

[carvalhoviniciusluiz]

in nestjs I have to extend from prismaclient,

class PrismaService extends PrismaClient

and in the tests, even mocking the methods, I'm receiving this message..

how do i solve?

warn(prisma-client) Already 10 Prisma Clients are actively running.

is there any way to tell the prism to disconnect its instance, something that stops afterEach?

[mytchdot]

Prisma docs on this:
Connecting and disconnecting - prisma.io

Calling the disconnect method on the afterEach works fine for me.

(The setup I have using this is using mocha: "^9.2.1" and chai: "^4.3.6")

[NoTuxNoBux]

Is there any way to silence this message? I think I might have a valid use case where this can happen expectedly by running Jest database tests in parallel with each using their own (e.g. SQLite) database - there is no problem with multiple active connections here.

My tests are passing, but since Keystone updated to a more recent Prisma version, I'm being spammed by these warnings when running all tests.

[queicherius]

Same here, we've resorted to overwriting the error:

const originalConsoleWarn = console.warn
console.warn = (...args) => {
  const prismaWarning = 'warn(prisma-client) There are already 10 instances of Prisma Client actively running.'
  if (args[0] === prismaWarning) return
  return originalConsoleWarn(...args)
}

[toman92]

Just to follow up. I wasn't able to reproduce this in a minimal project but I'm not seeing this message anymore after upgrading to version 3.12. I've upgraded again to v3.13 and I'm still not seeing this message. Also, this didn't cause any issues while I was seeing it.

[robhrt7]

Has anyone encountered an issue when Next.js build some number of static pages during the build, which require DB calls, and due to (assumed) high parallelization of these static page builds, there are multiple DB connections spawned simultaneously, tightly correlated with the number of pages being built.

The solution for hot reload does not seem to help in such case, as we always had it in our codebase.

Basically if we pre-build say 10 pages into static, through the build process the nextjs builder opens 10 connections to DB. The bigger problem is that these connections seem to stale, and it's unclear where to edit the code to force terminate them.

[vHeemstra]

Maybe this article helps? Best practice for instantiating PrismaClient with Next.js

[robhrt7]

We've tried everything could find in docs, including what's linked - we had that snippet already in the app. But it only helps solving the case for local development watcher, not the production build, which seems to spawn multiple instances of the app, each creating a connection and with no ability to share global.

[anesask]

Same issue here, have you found something on this issue?

[Jaysok]

For those who might face this problem in nestjs, below is what i did.

Although it is not that pretty, but it can squelch the warning message.

If you setup your test with beforeEach with Test.createTestingModule importing PrismaModule, the test creates PrismaClient every time it initializes TestingModule, which might cause the warning. Most of all, in my case calling $disconnect did not solve the problem. It seems the warning is about the number of PrismaClients not the number of connections.

The code below is simple workout of making PrismaClient single instance, while making multiple TestingModules in the tests.

your-service.spec.ts

import { Test, TestingModule } from '@nestjs/testing';
import { PrismaClient } from '@prisma/client';
import { PrismaModule } from '../prisma.module';

describe('YourService', () => {
  let service: YourService;
  const prismaClient = new PrismaClient(); // <-- (!)
  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      imports: [PrismaModule.forTest(prismaClient)], // see dynamic import of `PrismaModule` with existing client
      providers: [YourService],
    }).compile();

    service = module.get<YourService>(YourService);
  });
  // [...]

prisma.module.ts

import { DynamicModule, Global, Module } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';
import { PrismaService } from './prisma.service';

@Global()
@Module({
  providers: [PrismaService],
  exports: [PrismaService],
})
export class PrismaModule {
  // with the help of `DynamicModule` we can import `PrismaModule` with existing client.
  static forTest(prismaClient: PrismaClient): DynamicModule { 
    return {
      module: PrismaModule,
      providers: [
        {
          provide: PrismaService,
          useFactory: () => prismaClient as PrismaService,
        },
      ],
      exports: [PrismaService],
    };
  }
}

prisma.service.ts

import { INestApplication, Injectable, OnModuleInit } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit {
  async onModuleInit() {
    await this.$connect();
  }

  async enableShutdownHooks(app: INestApplication) {
    this.$on('beforeExit', async () => {
      await app.close();
    });
  }
}

[sdr0x07b6]

For normal application code, there are solutions like the Singleton pattern, as @nikolasburk showed us.

However, there are times when you are developing Prisma extends and want a new instance of PrismaClient for each test case.
new PrismaClient().$extends(myextends(options))

In this case, the singleton pattern would share the instance with all test cases.

I tried disconnecting explicitly for each test case instead of singleton. The warnings still did not go away, so I tried explicitly connecting and then explicitly disconnecting. The warnings still did not go away.

test('Test Case 1', async () => {
  const prisma = new PrismaClient().$extends(myextends(options));
  await prisma.$connect();
  // test...
  await prisma.$disconnect();
 });
 
test('Test Case 2', async () => {
  const prisma = new PrismaClient().$extends(myextends(options));
  await prisma.$connect();
  // test...
  await prisma.$disconnect();
 });
 
 ...

Doesn't $disconnect() improve this problem?

[KaramGhazzi]

i think in this case you would get that error anyway because you actually want to make multiple instances intentionally....for me i always throw prisma instance in a BeforeAll() lifecycle en then use that instance for all test cases...$disconnect() Disconnects from the database, but the instance still exist...but really interesting point, let me know if you find a solution for that!

[millsp]

Could you share a single PrismaClient instance between tests, and then apply an extension in each of your tests, and only disconnect once all the tests are finished?

[abulwafa]

Proposed solution (singleton pattern)

prisma.service.ts

import { Injectable, type OnModuleInit } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit {
  private static instance: PrismaService | undefined;

  public static getInstance(): PrismaService {
    if (!PrismaService.instance) {
      PrismaService.instance = new PrismaService();
    }
    return PrismaService.instance;
  }

  async onModuleInit(): Promise<void> {
    await this.$connect();
  }
}

prisma.module.ts

import { Global, Module } from '@nestjs/common';

import { PrismaService } from './prisma.service';

@Global()
@Module({
  providers: [
    {
      provide: PrismaService,
      useValue: PrismaService.getInstance(),
    },
  ],
  exports: [PrismaService],
})

export class PrismaModule {}

For any class or test file that injects prismaService as a dependency, will only get a single instance.

[guicuton]

The NestJS already manage as singletons the instances of providers when its imported into multiple modules right?
So, how this approach could help deals with the Too many connections issue?

[anton-johansson]

I have a multi-tenant application where I use Prisma to connect to multiple (hundreds) of databases with the same schema. I get this warning where I don't really want it, I need different connection pools. Is there a way to silence it?

[jakubriedl]

Same for us, we have 2 use-cases that we consider valid and would appreciate being able to silence the error.

1. mentioned here is multi-tenant application. Every tenant has their own schema, and to be able to connect to different schema every time we have different db url every time. Which means we need to create new PrismaClient for every customer/tenant.
2. also mentioned here is testing. We don't think mocking database calls is the right for us as most test in our app are about making mutations on complex model. And we need to make sure that doing a mutation will have the desired effect on the complex model. To isolate tests we create new schema for each of them (using beforeEach). And so every test connects to it's own schema ... so it creates new instance.

I understand the desire to warn users in the 90+% of use-cases but there are still use-cases where having many instances is valid. So having the ability to silence this error would be beneficial.

[umkara]

import { PrismaClient } from '@prisma/client';

declare global {
  var prisma: PrismaClient | undefined;
}

export const db = globalThis.prisma || new PrismaClient();

if (process.env.NODE_ENV != 'production') globalThis.prisma = db;

It declares a global variable named prisma with a type of PrismaClient | undefined. This allows the code to store the Prisma client globally, making it accessible throughout the application.

Prisma Client Initialization:
The db constant is created by either using the existing global prisma instance (if it exists) or by creating a new instance of PrismaClient. This ensures that only one instance of the Prisma client is used throughout the application.

Global Assignment in Development:
In a non-production environment (when process.env.NODE_ENV is not 'production'), the prisma global variable is assigned the value of the db constant. This is a development-oriented feature to make the Prisma client globally accessible for easier debugging and exploration.

[johnchonn]

I am using NextJS 14 App Router with Prisma ORM

At my project root, I have a folder called lib and within it, a file called prisma.ts and the contents are:

const prismaClientSingleton = () => {
  return new PrismaClient();
};

declare global {
  var prismaGlobal: undefined | ReturnType<typeof prismaClientSingleton>;
}

const prisma = globalThis.prismaGlobal ?? prismaClientSingleton();

export default prisma;

if (process.env.NODE_ENV !== 'production') globalThis.prismaGlobal = prisma;

But for some reason I am still getting this error:
warn(prisma-client) This is the 10th instance of Prisma Client being started. Make sure this is intentional.

Can anyone tell me what is going on..?

[umkara]

From the code you provided, it looks like you're trying to create a singleton pattern for the Prisma Client using prismaClientSingleton. However, there are a few potential issues in your implementation that could be causing this problem:

Conditional declaration of prismaGlobal: You're declaring prismaGlobal inside prismaClientSingleton, which means it's only accessible within that function scope. Instead, you should declare it globally so that it's accessible throughout your application.

Exporting the Prisma Client instance directly: You're exporting the Prisma Client instance directly from prisma.ts, which could lead to multiple instances being created if the file is imported multiple times.

import { PrismaClient } from '@prisma/client';

// Create a singleton function for Prisma Client
const prismaClientSingleton = () => {
  if (!globalThis.prismaGlobal) {
    globalThis.prismaGlobal = new PrismaClient();
  }
  return globalThis.prismaGlobal;
};

// Declare global variable prismaGlobal
declare global {
  var prismaGlobal: PrismaClient | undefined;
}

// Export the Prisma Client instance
const prisma = prismaClientSingleton();

export default prisma;

[johnchonn]

Thank you it worked!!

[umkara]

No problem👍🏻

[WebDevChandan]

This above warning indicates that you're initializing Prisma Client multiple times in your application.

• This could potentially lead to inefficiencies or unexpected behavior.
• In most cases, initializing Prisma Client once and reusing the instance throughout your application is the recommended approach for better performance and consistency.

Let's take a simple Example of a Next.js 14 Application:

/app/utility/prisma.js

import { PrismaClient } from "@prisma/client";

let prisma;

// Check if Prisma instance exists, if not, create a new one
if (process.env.NODE_ENV === 'production') {
    prisma = new PrismaClient();

} else {
    if (!global.prisma) {
        global.prisma = new PrismaClient();
    }
    prisma = global.prisma;
}

export default prisma;

/app/utility/userFunctions.js

import prisma from "./prisma";

export const fetchAllUsers = async () => {
    try {
        const allUsers = await prisma.user.findMany({
            include: {
                posts: true,
            }
        });
        return allUsers;
    } catch (error) {
        console.log(error);
        process.exit(1);
    }
}

/app/page.tsx

import { fetchAllUsers} from "@/utility/userFunctions"

export default async function Home() {
  const allUsers = await fetchAllUsers();

  console.log(allUsers);
  return (
    <h1>Hello World!</h1>
  );
}

[johnchonn]

Wow thank you so much for the examples provided I appreciate for writing such a detailed response! Things are working and looking good!