Issues with difference between dev and production environment
In the dev environment, I can use the Supabase pooler connection URL with no params at all to make queries with my Prisma client. However using the same connection URL when my code is deployed results in a pooling error upon the code reaching the very first query:
I have doubts that the issue is resource allocation issue because its failing on the first query and hitting that time limit seems ridiculous.
I have doubts that the issue is resource allocation issue because its failing on the first query and hitting that time limit seems ridiculous.
6 Replies
You've gone full bot mode! Let me fetch that AI answer for you ASAP.
Your observation is valid: if the error occurs on the very first query in production, it's unlikely to be a simple resource exhaustion issue. Several users have reported similar issues with Prisma and Supabase poolers, especially in serverless or edge environments. The error message:
can occur even when the database is not at its connection limit, and sometimes immediately, not after the expected timeout period. This has been observed with Supabase's Supavisor pooler, where connections may be dropped between the pooler and the database, but Prisma is unaware and hangs or throws a timeout error on the first query. Switching to a direct IPv4 connection (bypassing the pooler) resolved the issue for some users, suggesting the problem may be with how Prisma interacts with the pooler in certain environments, not with your resource allocation or query volume. This is especially true in production-like environments (e.g., Vercel, AWS Lambda) where networking and connection reuse behave differently than in local dev environments see discussion.
Additionally, some users found that setting
connection_limit=1 and/or disabling the pool timeout (pool_timeout=0) can help, but these are workarounds and may not address the root cause. If you are using Supabase's pooler, consider testing with a direct connection or reaching out to Supabase support, as there may be underlying issues with dropped connections that Prisma cannot detect see user report.
In summary: This is a known issue with Prisma and some connection poolers in production, not likely a resource allocation problem. Consider the above workarounds or direct connections, and monitor related GitHub issues for updates.
š¤ Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly.
In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.This is a where the hanging code is, keep in mind this is at the very first query I make using Prisma (other queries are made before hand with Supabase), so I doubt I disabling a timeout would fix anything.
Why would this difference exist between prod and dev
I believe Supabase gives you 3 connection strings
Direct, Session pooler and Transaction pooler connection string.
Which one do you use in your production environment?
I fixed this by enabling the query compiler
Sounds good! š