PostgreSQL Error 53300: Too many connections
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?
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
- 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.
- 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.
- 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
const client = await pool.connect(); const { rows } = await client.query('SELECT * FROM jobs'); client.release(); // skipped if query throws
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
$ for i in $(seq 1 120); do psql -c "SELECT pg_sleep(30)" >/dev/null & done; waitRun 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