Inconsistency in not generating prepared statements when using Prisma Accelerate
Hello,
I am connecting to our Supabase Supavisor Transactional Connection Pooler using the appropriate connection url ending with pgbouncer true, connection limit 1.
My backend is hosted using Cloudflare Workers serverless using hono.js and REST api.
I am experiencing inconsistences when using Prisma to call our database, requiring refresh of our supabase database around every 24 hours to solve the issue. The issue occurs intermitenntly throughougt the day (every 200 or so requests maybe 1 error), but after 24 hours, the whole thing breaks completely and will not work until the database server restart is performed. The error can also be solved after refreshing about like 40 times, it will work again for a few tries, then will break again.
It seems like others have experienced this issue. I am posting this after refreshing our server so i can't provide images of error just yet, but the errors are all "prepared statement already exists" with a number that grows.
Thanks for the help, very appreciated
Jason
Edit:
An alternate thread with the same issue https://discord.com/channels/937751382725886062/1270035810791723039/1270035810791723039
Solution:Jump to solution
Hi apologies for the alte response, i didnt get a notifaction about a reply here. I posted in the supabase discord and the error was fixed by using Prisma Accelerate using port 5432 (Session Mode) to connect to Supabase and hence not using supabases pooling. It seems like using both pooling stratgies causes the inconsistency
(in fact it seems like you can only do it this way in serverless environments using prisma accelerate)....
2 Replies
Hey,
Can you please try using Prisma Accelerate without pgbouncer flag?
Considering that Prisma Accelerate also has a built in connection pooler and pgBouncer is also a connection pooler.
Combining both of them might cause an issue. What happens if you don't use pgbouncer?
Solution
Hi apologies for the alte response, i didnt get a notifaction about a reply here. I posted in the supabase discord and the error was fixed by using Prisma Accelerate using port 5432 (Session Mode) to connect to Supabase and hence not using supabases pooling. It seems like using both pooling stratgies causes the inconsistency
(in fact it seems like you can only do it this way in serverless environments using prisma accelerate).