I was wondering how to handle Prisma connections with Supabase which uses supavisor for its connection pool with Fluid Compute.

My current apps have specific high traffic times and I can handle connections by using ?pgbouncer=true&connection_limit=1&pool_timeout=30, which essentially makes every function use only 1 connection per invocation. This works well as I let Supavisor do the management of the pooling with a connection pool of around 30.

With fluid compute, what I understand is that functions will stay warm for a moment and will be reused.

My code currently only puts prisma as a global variable when running the NextJs dev server and in production it creates a new prisma instance for each function invocation.

With Fluid compute, does that change how I need to manage connections? Should I put prisma as a global just like I do with my development server in order to handle multiple requests coming to my warm function to avoid going consuming too much connections from supavisor's connection pool?

Moreover, if I put prisma as a global variable, wouldn't long queries actually make other requests queue up waiting for the connection to be released?

Here is a sample code of my current prisma.ts file

1
declare global {
2
  // eslint-disable-next-line no-var
3
  var prisma: PrismaClient | undefined;
4
}
5

6
const createPrismaClientWithEncryption = () => {
7
  return new PrismaClient({
8
    datasources: {
9
      db: {
10
        url: process.env.DATABASE_URL,
11
      },
12
    },
13
  }).$extends(fieldEncryptionExtension()) as PrismaClient;
14
};
15

16
export const prisma: PrismaClient = global.prisma || createPrismaClientWithEncryption();
17

18
if (!isProd()) { // store prisma in global only for non production environments (aka non-serverless)
19
  global.prisma = prisma;
20
}