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

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.

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: Something is holding connections and not giving them back, or the pool is just too small. Use one shared PrismaClient instance, set connection_limit to match your database, raise pool_timeout for slow cold starts, and put serverless traffic behind a pooler like PgBouncer or Supavisor.

Timed out fetching a new connection from the connection pool. (Current connection pool timeout: 10, connection limit: 5)

Steps

1. Make sure you create exactly one client and reuse it:

   // lib/prisma.ts
   import { PrismaClient } from '@prisma/client'
   const globalForPrisma = globalThis as unknown as { prisma?: PrismaClient }
   export const prisma = globalForPrisma.prisma ?? new PrismaClient()
   if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma

   Expected: connection count on the database stops climbing with every request.

2. Size the pool in the connection string:

   postgresql://YOUR_HOST:5432/mydb?connection_limit=10&pool_timeout=20

   Expected: pool_timeout=20 gives slow queries twice as long to get a connection before P2024 fires.

3. Serverless (Vercel, Lambda): point DATABASE_URL at your pooler in transaction mode with ?pgbouncer=true, and keep a direct URL for migrations. Expected: P2024 under burst traffic drops sharply because the pooler multiplexes.

4. Find the leak: log prisma.$queryRaw connection counts or watch pg_stat_activity during the failure window. Expected: you see connections stuck in idle in transaction, which means a transaction was opened and never committed or rolled back.

When to use

• The exact code is P2024, intermittent, worse under load or cold starts
• Connection count on the database climbs until queries start timing out

When not to use

• P1001: nothing connects at all, the server is unreachable
• Every query is slow: that is a query performance problem, not pool exhaustion

Compatibility

Prisma Client 4.x through 6.x. PostgreSQL and MySQL. Supabase, Neon, RDS.

Variant phrasing: P2024 only during next build / prerender

Build-time data fetching opens many parallel connections. Raising pool_timeout for the build environment is the documented quick fix.

Variant phrasing: P2024 with connection_limit=1

A limit of 1 serializes everything; any concurrent request waits. Raise it to at least your framework's concurrency.

Why it happens

Prisma keeps a pool of database connections capped at connection_limit. Each query borrows one and returns it when done. If clients multiply (one per request), transactions leak, or the limit is smaller than your concurrency, new queries wait longer than pool_timeout and Prisma throws P2024.

Edge cases

• Long-running transactions hold a connection for their whole life; keep transactions short.
• connection_limit counts per client instance, so two instances double your real connections.
• Statement timeouts on the database side surface as different errors; P2024 is specifically the pool wait expiring.

A production app started throwing P2024 timeouts during builds and traffic spikes. The investigation found the pool was exhausted: too many client instances and a pool timeout too tight for cold starts. The fix that landed: raise pooltimeout for the build environment and consolidate on a single shared PrismaClient instance, with connectionlimit tuned to the database's max connections. After the change the timeouts stopped. Source: https://github.com/sheesha-labs/indus-hydraulics/commit/336456f1c638e51df2b47681c5e37cf6f0fc43ff