PostgreSQLRunbook 0/4 done
53300

PostgreSQL Error 53300: Too many connections

Critical↻ Retryable · exponential backoffHTTP 503 Service UnavailableDatabase
TL;DR · 10-second read

Every slot in max_connections is in use, so Postgres refuses new sessions. Put a pooler (PgBouncer, Supavisor, Neon pooled endpoint) in front and cap each app instance's pool size.

Identify: does your log match?

What you see · exact log / response
psql: error: connection to server at "10.0.4.12", port 5432 failed: FATAL:  sorry, too many clients already

FATAL:  remaining connection slots are reserved for roles with the SUPERUSER attribute
  1. High

    Serverless functions each open a pool

    Every Lambda or Vercel function instance creates its own pool of N connections. 50 concurrent instances × 10 connections exceeds the default max_connections of 100.

  2. Medium

    Leaked connections never released

    Code calls pool.connect() and forgets client.release() on an error path. The pool grows until the server is full.

  3. Medium

    Dev hot-reload creates new clients

    Next.js or nodemon reloads re-run new PrismaClient() or new Pool() at module scope, leaving old pools connected.

Fix

Always release clients and cap pool size

✕ Broken · Node.js
const client = await pool.connect();
const { rows } = await client.query('SELECT * FROM jobs');
client.release(); // skipped if query throws
✓ Fixed · Node.js
const pool = new Pool({ max: 5, idleTimeoutMillis: 10000 });

const client = await pool.connect();
try {
  const { rows } = await client.query('SELECT * FROM jobs');
  return rows;
} finally {
  client.release();
}

finally guarantees release on every path. A small max per instance keeps instances × max under the server limit.

Verify: reproduce it on purpose

Reproduce locally · bash
$ for i in $(seq 1 120); do psql -c "SELECT pg_sleep(30)" >/dev/null & done; wait

Run it against a dev environment to trigger 53300 on purpose and test your error handler.

Prevent

  • Budget connections: instances × pool max + admin headroom < max_connections.
  • Set idle_in_transaction_session_timeout to kill stuck sessions.
  • Use a single PrismaClient/Pool per process (globalThis in dev).

FAQ

Should I just raise max_connections?

Only modestly. Each backend uses several MB of RAM, and throughput degrades well before a few hundred active connections; a pooler scales further.

Why do I still have connections after my app stopped?

TCP keepalives may not have detected the dead client yet. Terminate them with SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'app'.

What is the difference between 53300 and Prisma P2024?

53300 means the Postgres server is full. P2024 means Prisma's own client-side pool had no free connection within pool_timeout.

Related errors

Last verified 2026-10-21 · Source: Official Appendix A error codes (errcodes.txt in the postgres repo) · Official docs ↗ · ~9,900 searches/mo