P
Prisma•2w ago
Giovani Granzotto

Dealing with database timeouts with prisma and vercel fluid compute

Hello, we've been getting timeout errors on our production vercel deployment: 
PrismaClientKnownRequestError: 
Invalid `prisma.store.findUnique()` invocation:


Timed out fetching a new connection from the connection pool. More info: http://pris.ly/d/connection-pool (Current connection pool timeout: 10, connection limit: 7)
...
...
 {
  code: 'P2024',
  clientVersion: '6.2.1',
  meta: { modelName: 'Store', connection_limit: 7, timeout: 10 }
}
PrismaClientKnownRequestError: 
Invalid `prisma.store.findUnique()` invocation:


Timed out fetching a new connection from the connection pool. More info: http://pris.ly/d/connection-pool (Current connection pool timeout: 10, connection limit: 7)
...
...
 {
  code: 'P2024',
  clientVersion: '6.2.1',
  meta: { modelName: 'Store', connection_limit: 7, timeout: 10 }
}
We're using neon with pgbouncer as a connection pooler. Vercel is running in fluid compute mode. The prisma client is instantiated as a "global" singleton very similarly to this stackoverflow answer. We have around 470 weekly active users and looking at the connection and compute monitoring on the neon console I would expect us to be nowhere near any scaling limits on the database side. My first instinct would be to just increase the timeout, which I haven't been able to figure out yet given the serverless obtuseness around it. I'm struggling to come up with theories as to why this is happening, but there's one that I think might be plausible. - The connection limit works per Prisma Client. - We always use the Prisma Client imported from a "singleton". - Since it's serverless, theoretically the singleton doesn't exist because every time a function runs, it's stateless and isolated, so this wouldn't matter. - We recently changed the Vercel mode to run as "fluid compute", where it "reuses" endpoints that are already running to handle other requests while they are waiting for a response from the database, API, etc. - This would imply that endpoints receiving many simultaneous requests would indeed be creating many connections and exceeding Prisma's limit. Does this even make sense? Since the pooling is already handled at the database with pgbouncer I would think that there wouldn't need to be a limit on prisma.
3 Replies
Prisma AI Help
Prisma AI Help•2w ago
You're in no rush, so we'll let a dev step in. Enjoy your coffee, or drop into #ask-ai if you get antsy for a second opinion!
Giovani Granzotto
Giovani GranzottoOP•2w ago
Also, I've been made aware that there's an attachdatabasepool hook in vercel that's supposed to be used to cleanup database connection pools after running serverless functions. Do you know if this needs to be used with prisma in any way?
@vercel/functions API Reference
Learn about available APIs when working with Vercel Functions.
Nurul
Nurul•2w ago
The error you see (P2024) means all connections in the pool are busy, and Prisma could not get a free connection within the timeout window. From the error message it seems that the connection limit is set to 7. I assume you haven't configured this limit?
My first instinct would be to just increase the timeout, which I haven't been able to figure out yet given the serverless obtuseness around it.
Could you please elaborate on this? Do you mean that increasing connection_limit and pool_timeout doesn't work? postgresql://user:pass@host/db?pgbouncer=true&connection_limit=X&pool_timeout=Y

Did you find this page helpful?