Hey, has anyone seen Supabase Storage consume a large number of Postgres connections and leave them idle?
General situation:
Current pg_stat_activity aggregation looks roughly like this: usename,application_name,client_addr,state,count postgres,Supavisor,[redacted-ipv6],idle,92 supabase_storage_admin,Supabase Storage API,127.0.0.1,idle,91 supabase_storage_admin,Supabase Storage API,::1,idle,68 pgbouncer,Supabase Storage API,127.0.0.1,idle,43 pgbouncer,Supabase Storage API,::1,idle,26 authenticator,postgrest,::1,idle,15 postgres,Supavisor,[redacted-ipv6],idle in transaction,7
Questions:
Would love any help from people who have seen this before.
The user reports that Supabase Storage is consuming a large number of Postgres connections, leaving them idle and eventually exhausting connection slots. This leads to failed uploads and unstable app services. The user seeks advice on whether this behavior is expected and potential mitigations.
Don't recall seeing this and can't find anything in a quick search.
Anything happening in the storage log when this starts to happen? Seems like overloading both the DB and Storage might cause this as connections build up to be handled and are waiting for DB to respond back. (not sure if that would show idle or not).
Restart instance and larger size would be two options while waiting for Support advice.
Check your query performance report to see if your storage RLS queries are making up a large percentage of your query time.