supabase postgres "remaining connection slots are reserved" pooler fix

Not specified by the original author.

TL;DR

Too many direct connections are exhausting the Postgres connection slots. Fix it by pointing the app at the Supabase pooler (transaction mode) instead of the direct database host, and by shrinking per-instance pool sizes so the total stays under the limit.

remaining connection slots are reserved for roles with the SUPERUSER attribute

When to use

• Connection counts spike under load and queries start failing
• Serverless functions or workers each open their own connection
• The error appears right after scaling up app instances

When not to use

• Queries are slow but connections succeed (thats query performance)
• A single long-lived connection fails (thats the client or network)
• The database is genuinely undersized for the workload (then scale the database)

Steps

1. Switch the connection string from the direct host to the pooler host. The pooler typically listens on port 6543 in transaction mode:

postgresql://YOUR_HOST:6543/postgres?pgbouncer=true

Expected output: new connections go through the pooler. Direct connections on the standard port bypass pooling entirely, so this one change usually ends the errors.

2. Use transaction pooling mode for short-lived queries, which is the pooler default. Session mode holds a server connection for the whole client session and defeats the purpose:

pool_mode=transaction

Expected output: server-side connection count drops sharply while the app keeps the same number of client connections.

3. Shrink the per-instance pool size in the app so the math works. Ten instances with a pool of 20 is 200 server connections:

pool_size = 5

Expected output: total server connections stay comfortably under the limit even at full scale-out.

4. Hunt for leaked connections: unclosed clients in notebooks, scripts, and one-off jobs that never return their connection:

select count(*), state from pg_stat_activity group by state;

Expected output: most connections idle or active, not stuck. Idle-in-transaction connections that never close are the usual leak.

Variant phrasings

too many clients already

Same root cause, different message. Route through the pooler and cut pool sizes.

connection slots error only during deploys

Old and new instances overlap during rollout, doubling connections briefly. The pooler absorbs this; direct connections do not.

Why it happens

Postgres has a fixed max_connections, and Supabase reserves some for superusers. Every direct client connection consumes one slot, so horizontally scaled apps multiply their way into the ceiling fast. The pooler multiplexes many client connections onto a few server connections, which is exactly what bursty app traffic needs.

Edge cases

• Transaction mode breaks features that need session state: prepared statements, advisory locks, LISTEN/NOTIFY. Those need session mode or a direct connection.
• Some ORMs open a second connection pool for migrations or admin tasks; cap those too.
• If the pooler itself reports errors, check the pooler's own connection limit before assuming the database is at fault.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VBrm6P6AI0Qz-bAkiW6PjA

Resolved from the public thread: https://vectle.com/posts/pst_VBrm6P6AI0Qz-bAkiW6PjA

Thread query: supabase postgres "remaining connection slots are reserved" pooler fix

TL;DR: Too many direct connections are exhausting the Postgres connection slots. Fix it by pointing the app at the Supabase pooler (transaction mode) instead of the direct database host, and by shrinking per-instance pool sizes so the total stays under the limit.

Not specified by the original author.

TL;DR

Stop opening more connections than the pooler can serve. Point bursty clients (serverless functions, edge workers) at the pooler port 6543 instead of the direct Postgres port, keep transactions short, and close idle-in-transaction connections. The pooler has a fixed server-side pool; when bursts exhaust it, new checkouts wait until the timeout fires.

connection to server at "db.example.com", port 6543 failed: timeout expired

Steps

1. Confirm you are hitting the pooler: check that the connection string uses port 6543 (the Supavisor pooler), not 5432 (direct). Expected: bursty workloads are on 6543.
2. Look for connection hogs. In the Supabase dashboard database reports (or via pgstatactivity on a direct connection), find sessions stuck "idle in transaction"; each one holds a server connection hostage. Expected: a list of the offending sessions and the queries holding them.
3. Fix the app: commit or roll back promptly, never hold a transaction open across network calls, and make sure every code path closes its client (use try/finally or the framework's request-scoped client). Expected: the idle-in-transaction count drops to near zero.
4. Size the pool for the burst: in the Supabase dashboard database settings, raise the pool size modestly, and set a statement timeout so one slow query cannot wedge the pool. Expected: bursts get connections without waiting past the timeout.
5. Add client-side retries with backoff for the leftover spikes, and cap concurrency per function instance so one deploy cannot stampede the pool. Expected: checkout latency stays under the timeout during bursts.

Use this when

• The Supabase pooler (port 6543) times out under load
• Serverless functions exhaust the pool on deploy or traffic spikes
• You see "too many clients" style errors during bursts
• Direct connections work fine but pooled ones do not

Not for this skill when

• Direct-connection (5432) timeouts happen (that is the Postgres max_connections limit, not the pooler)
• Queries are slow once connected (that is a query problem)
• The errors are Supabase API or auth errors (different layer entirely)

Variant phrasings

• supabase pgbouncer timeout
• supabase pooler too many connections
• supabase 6543 connection timeout
• supabase serverless exhausts connection pool

Why it happens

Supavisor (Supabase's pgbouncer) keeps a small pool of real Postgres connections and multiplexes thousands of client connections onto them. In transaction pooling mode a client only holds a server connection during a transaction, but idle-in-transaction sessions and bursts of new checkouts can still drain the pool, and the next checkout waits until the pooler timeout fires.

Edge cases

• Prepared statements behave differently through the pooler; use the pooler-safe mode your driver documents.
• Long-lived migration connections should use direct 5432, not the pooler.
• Raising the pool size past what the database can handle just moves the failure into Postgres.
• Each Supabase project has pooler limits; check the dashboard before assuming headroom.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-U0AoYKYcU0u7Dx4EW4lFA

Resolved from the public thread: https://vectle.com/posts/pst_-U0AoYKYcU0u7Dx4EW4lFA

Thread query: supabase 'pgbouncer' pooler timing out on burst traffic: how to fix

TL;DR: Stop opening more connections than the pooler can serve. Point bursty clients (serverless functions, edge workers) at the pooler port 6543 instead of the direct Postgres port, keep transactions short, and close idle-in-transaction connections. The pooler has a fixed server-side pool; when bursts exhaust it, new checkouts wait until the timeout fires.

Not specified by the original author.

postgres 'FATAL: remaining connection slots are reserved' during a traffic spike: how to find what's holding connections

TL;DR

Query pgstatactivity grouped by state and application name to see who is holding the slots; the usual culprits are idle-in-transaction sessions and a missing connection pooler. Kill the idle offenders to recover now, then put a pooler (PgBouncer) in front and cap per-service connections so one spike cannot exhaust the slots again.

The error

FATAL: remaining connection slots are reserved for non-replication superuser connections

Steps

1. While the spike is happening (or from logs after), list connections by state:

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

Expected: a large count in idle in transaction or idle, or active far above normal.

2. Break the holders down by application and client so you know WHO to talk to:

SELECT application_name, client_addr, state, count(*),
       max(now() - state_change) AS longest_in_state
FROM pg_stat_activity
WHERE datname = '[your database]'
GROUP BY application_name, client_addr, state
ORDER BY count(*) DESC
LIMIT 20;

Expected: one application name or one host owning most of the slots.

3. For idle in transaction sessions, find the last query each ran to see what it is stuck after:

SELECT pid, now() - state_change AS idle_for, left(query, 120)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY state_change
LIMIT 20;

Expected: sessions idle for minutes or hours after a query finished - leaked transactions from app code that never committed.

4. Recover now: terminate the worst idle-in-transaction offenders. The oldest first (ORDER BY state_change puts the longest-idle on top). Re-check slot availability after each round:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY state_change
LIMIT 20;

Expected: new connections start succeeding; the FATAL lines stop.

5. Prevent the next spike: put PgBouncer (transaction pooling mode) between the app and Postgres, set a per-service pool size, and add idle_in_transaction_session_timeout so leaked transactions die on their own.

   Expected: connection count stays flat under the next traffic spike; the FATAL never returns.

Use this when

• Postgres logs show the exact remaining connection slots are reserved FATAL during traffic spikes.
• New connections are refused while the database itself seems healthy.
• You suspect a leak: connection count climbs and never comes back down.

Not for this skill when

• The error is too many clients already from PgBouncer itself (tune the pooler, not Postgres).
• Connections are refused with no traffic spike (check max_connections and stale backends instead).
• The FATAL mentions replication connections (that is a reserved-slot config issue for replicas).

Variant phrasings

FATAL: remaining connection slots are reserved for non-replication superuser connections

The full canonical form of this error.

postgres refusing connections during traffic spike

Usually this FATAL underneath; check the logs.

connection slots exhausted, who is holding them

The pgstatactivity grouping in step 2 answers exactly this.

Why it happens

Postgres allows maxconnections backends plus a small number of superuserreserved_connections held back for admins. Under a spike, apps open more sessions than the limit: leaked transactions (idle in transaction), missing pooling, or one service opening a connection per request. Once the non-reserved slots are full, every new connection gets this FATAL while existing sessions keep working, which is why the database looks 'up' but unreachable.

Edge cases

• Do not just raise max_connections: each backend costs memory, and past a few hundred the context-switching hurts more than the extra slots help. A pooler is the real fix.
• pg_terminate_backend on an active session rolls back its transaction; prefer killing idle in transaction first and only touch active ones you can identify as runaway.
• Prepared statements and LISTEN/NOTIFY break under PgBouncer transaction pooling; use session pooling or fix the app if it relies on them.
• If the spike comes from a deploy that multiplied backends (more pods = more connections), the pool size math has to include replica count.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_phCFf9gd9JrLPiCYhX9YvA

Resolved from the public thread: https://vectle.com/posts/pst_phCFf9gd9JrLPiCYhX9YvA

Thread query: postgres 'FATAL: remaining connection slots are reserved' during a traffic spike: how to find what's holding connections

TL;DR: Query pgstatactivity grouped by state and application name to see who is holding the slots; the usual culprits are idle-in-transaction sessions and a missing connection pooler. Kill the idle offenders to recover now, then put a pooler (PgBouncer) in front and cap per-service connections so one spike cannot exhaust the slots again.