I have a remix application running on vercel, which uses prisma to connect to a postgres DB on supabase. We use supabase’s transactional mode and pooler and set max_connections=1&pgbouncer=true in our prisma connection string.
We recently had a couple of spikes in requests that let to the supabase returning “FATAL Max connection limit reached” errors. This is all perfectly understandable and we need to scale up our instance a little and look at connection usage.
However, when this happened our application because unavailable/unresponsive on vercel even when timeout has lapsed and we’d expect the DB to be accepting connections again. The only way to restart things were to redeploy the application, which fixed thins immedately.
I am trying to understand why this. would be the case and looking for any suggestions people have or input from people who have experienced/safeguarded-against this. Right now I am wondering if:
There is some caching at play keeping the application apparently down.
The serverless functions crashed, maxed out and could not recover (i don’t know where or how to find logs on this though)
The connections were being held open somehow
the DB was refusing further connections from the application server because of some anti-dos feature (asking over at supabase on this one)
Any help, suggestions of how to investigate are appreciated
Best
Hi @stevejpurves! You should be able to find more error details in the runtime logs. Clicking on any row in the logs will bring up a panel with additional details about that item.
Normally you’d want to have some sort of connection pooling setup to avoid too many connections. Supabase does this by default, but there’s still a possibility to run out connections.
Yes we have connection pooling in place and are using transactional connection to supabase that utilizes that. I realise we can scale up to avoid the issue at a given level of traffic and those guides in the links you shared are indeed useful.
However, to better phrase my question:
why, after supabase connections become available again, do the vercel functions not just recover and begin processing new requests? why is a redeploy required to make the application responsive again?
I think that understanding the factors behind that part of the issue might help make application changes more gracefully handle things when/if a max connection limit is hit in future. There is nothing in the runtime logs that helps with that, but i am wondering if there is another place to look ot whether monitoring will help pin this down in future.