FATAL: sorry, too many clients already (Postgres / Supabase)

Fix it yourself

Follow the repair

1. Confirm it is connections, and see who holds them. The error text is unambiguous — "too many clients already" (code 53300) or "remaining connection slots are reserved". If you can still get into the Supabase dashboard, the Database section shows current connections and what is using them; a wall of connections from your app's address confirms the diagnosis. Do not start by upgrading the plan: a bigger instance raises the limit but multiplies the same leak, and pooled connections solve it at the current tier in most cases.
2. Switch app traffic to the pooler address. In the Supabase dashboard, open your project's Database settings and find the connection pooling (Supavisor) connection string — a different host ending in pooler.supabase.com. Your app code should use the transaction mode string on port 6543. Transaction mode hands a real connection to your app only for the length of a transaction, then returns it to the shared pool, so thousands of app instances share a small number of actual database connections:

   # Direct (what causes the pile-up) — db.yourproject.supabase.co:5432
   # Pooler, transaction mode (what fixes it) — note the host and port 6543
   postgres://postgres.yourproject:[password]@aws-0-[region].pooler.supabase.com:6543/postgres

   Update this in your hosting provider's environment settings (for example DATABASE_URL) and redeploy.
3. If you use Prisma, cap the pool and add the pooler flag. Two connection strings, two jobs: the pooled one for the app, a direct one for migrations. Set them up like this:

   # App traffic — pooled, one connection per instance
   DATABASE_URL="postgres://...pooler.supabase.com:6543/postgres?pgbouncer=true&connection_limit=1"
   
   # Migrations only — direct connection
   DIRECT_URL="postgres://...db.yourproject.supabase.co:5432/postgres"

   The pgbouncer=true flag tells Prisma the pooler is in charge (it adjusts features that transaction pooling cannot support), connection_limit=1 stops each serverless instance from opening a handful, and DIRECT_URL is referenced in your Prisma schema's datasource so migrations keep working.
4. Stop opening extra clients in code. Search for places that construct a new database client per request or per function call — a fresh Prisma client inside a route handler is the classic. Create one client at module level and reuse it; in development, attach it to a global variable so hot reloads do not stack up new clients on every save. Each stray client is a pool of its own.
5. Clear out the squatters. Old deployments, forgotten staging apps, local dev servers, and one-off scripts all hold slots. Restart or redeploy the app to drop its existing direct connections after switching URLs, shut down dev servers you are not using, and if connections from a dead process refuse to leave, the dashboard's database controls (or restarting the database as a last resort) will clear them. This is also the moment to check whether something is leaking slowly: if the count climbs steadily even at flat traffic, a code path opens connections without closing them — find it before it refills the pool.
6. Verify under the conditions that broke it. Redeploy with the pooler settings, then reproduce the traffic pattern that caused the failure — the same pages, the same burst. Watch the connection count in the dashboard while you do: with pooling, app traffic should register as a small, steady number instead of a staircase to the ceiling. Keep the direct connection string only where it belongs — migrations and database admin tools — and leave app code on the pooler permanently, not as a temporary patch.