Supavisor Session Mode (5432) not releasing connections from application (Softr.io client)

[Souej]

TL;DR: connection leak between Softr and Supavisor causing 110+ "zombie" connections and app crashes with only 1 active user on a Large Plan

hello all,

I am seeking help with a critical connection issue affecting my Softr applications powered by Supabase. I am running on a Large Compute Plan ($110/mo), but my project becomes unusable every few hours due to connection exhaustion.

The Issue: Despite having only 1 active user, the database connection count spikes to 130+. More alarmingly, the connections remain at 110 throughout the night when there are 0 users active. It appears that sessions are being held indefinitely by the pooler and are never released. Every morning I have to manually restart the project in the Supabase dashboard to clear these "zombie" connections so my client can log in.

details:
Connection: Using the Supavisor Pooler on port 5432 (Session Mode).
Pool Settings: I've tested various Pool Sizes (45, 72, 96, 128).
Observation: In the browser DevTools, I see fetches being made every 8-9 seconds. When the pool is saturated, these fetch times jump from a few ms to 11.4 seconds or fail with 400 errors.
Softr support claims they only maintain 5 concurrent connections, but Supavisor shows 70-110 active client sessions from their IP.

My Question: I am at a total loss here. Based on the behavior where connections stay at 110+ during the night, I'm trying to figure out where the breakdown occurs: is Softr failing to close sessions properly, or is Supavisor (Session Mode) failing to reap idle sessions? Or am I missing a fundamental configuration step for this specific stack?

Any insights, similar experiences, or advice on how to debug this further would be hugely appreciated! 😊

[nissimlavy]

This pattern usually means "connection per request" + "sessions never torn down".

A few concrete checks that will tell you where the leak is:

1. Supavisor mode: if you’re using Session mode, each client can hold a session open. For HTTP/REST-style traffic (Softr polling every ~8–9s), you almost always want Transaction mode, not Session mode, so idle sessions can be returned to the pool between requests.

2. Confirm what’s actually opening the connections:

• In Postgres, check active sessions by app/user/addr.
• Look at state + idle duration. If you see lots of “idle in transaction” or long-lived “idle” sessions, you’ve found the culprit.
• Check whether they all share the same application_name or come from a single NAT IP (Softr/edge).

3. The 8–9 second fetches are a huge tell. If Softr is doing frequent polling (auth/session refresh, data sync, etc.), and each poll opens a new DB session (or keeps one open), you’ll saturate a pool fast even with 1 “human” user.

4. Quick isolation test: disable the Softr app for 10–15 minutes (or point it at a dummy project) and watch Supavisor. If connections drop quickly, it’s almost certainly the client behavior. If they do not drop, you’re looking at pooler config/idle reaping or a server-side transaction that never completes.

That graph basically rules out “real load”.

Connections staying pinned at ~110 with 0 users means sessions are not being released. This is almost always Session mode + polling clients.

For Softr / REST-style traffic you generally want Supavisor in Transaction mode so idle sessions return to the pool between requests.

The 8–9s fetch interval is a giveaway, each poll can pin or reopen a session.
Quick way to confirm:

• Switch to Transaction mode
• Or temporarily disable Softr and watch connections decay

If they drop quickly, it’s client behavior + pooling mode, not Postgres capacity.