FATAL: remaining connection slots are reserved for non-replication superuser connections
We started seeing this error sometimes over the last few days...
We are mainly using @supabase/supabase-js in node. We are runing ~10-15 queries per second there. (The error came from here)
We also connect to the connection pooler for an internal monitor (low traffic, a handful of < 1s queries being run every 10 minutes)
Are there issues with combining these connection methods? Any ideas what could be causing the error?
15 Replies
have you tried increasing your pool size in the database settings?
Thx for quick response. Not yet.
Is there any reason we should not bump this to the maximum our plan allows for? (Assuming CPU, mem, etc looks ok)
Of note, these are not realtime connections. I'm assuming it's tracking the same metric?
realtime connections are something totally different. Those use websockets.
Supabase-js goes thru PostgREST which has its own pooler and comes in as authenticator role in the the role info view where you can see connections per role.
Got it. I just found what I was looking for. It's listed under compute add-ons: https://supabase.com/docs/guides/platform/compute-add-ons
Compute Add-ons | Supabase Docs
Learn about your project's instance and additional add-ons.
I don't think your 10-15 query load per second is going to tax PostgREST as far as connections. Are any other roles using alot of connections?
I was thinking the same thing. Even for query optimization I would prefer to just have the sql. It's only one role.
(the project changed directions)
It's a long-running process, so I'm thinking we will manage our own pool with
pgWhat is the long-running process?
Also, for anyone else stumbling here, exact connection limits for your plan are here: https://supabase.com/dashboard/project/{your-project-id}/settings/addons
Add ons | Supabase
Supabase Studio
It's a daemon-type system. Looping and continuously querying.
separately, there is an event system which is more ephemeral
neither is serverless
Still not clear, but does not probably matter. PostgREST calls from REST API do not maintain any connection to the database. They do their thing then PostgREST is free to reuse the connection or not.
Good to know. Initially I used the client / REST API because I figure you guys would have optimized for volatility / worst-case traffic patterns. Sounds like that is a good option still.
Thanks for the background info, and super fast response
"you guys" most of us here are users.
You're not on Supabase team?? I thought I saw a badge
I'm part of their Supasquad which is a users program they have.
Got it.
Well, thanks for the help anyway. Much appreciated.