remaining connection slots are reserved for roles with the SUPERUSER attribute

By Ohad Krispin, founder of VibeRaven · LinkedIn

"remaining connection slots are reserved for roles with the SUPERUSER attribute" (SQLSTATE 53300, too_many_connections) means your app has opened as many direct Postgres connections as the Neon compute allows, so Postgres keeps the last slots for superusers and refuses yours. On Vercel every function instance that creates its own client holds its own connections, so traffic fills the 104 connections of a 0.25 CU compute, of which Neon reserves 7. Point DATABASE_URL at Neon's pooled host, the one with -pooler in the endpoint name, which accepts up to 10,000 client connections through PgBouncer, and create one pool per instance at module scope. Keep the direct host for migrations and pg_dump. Postgres 15 and older word the error "remaining connection slots are reserved for non-replication superuser connections". Reproduced on Postgres 17.11 on 2026-10-27.

Use this from your agent

Claude Code: 4 read-only tools; cannot see your repo.

claude mcp add --transport http viberaven https://viberaven.dev/mcp

Codex: same server, in ~/.codex/config.toml.

[mcp_servers.viberaven]
url = "https://viberaven.dev/mcp"

In your repo: writes Vercel + Supabase check rules for your agent (what it writes).
```
npx -y viberaven init
```

Postgres 17.11 with 10 connections, 3 reserved: the app role is refused with 53300 remaining connection slots are reserved, and the last superuser with sorry, too many clients already.

Same error on Supabase instead of Neon? See the Supabase pooler fix for Vercel functions.

The two messages behind 53300

Postgres raises both with SQLSTATE 53300. A role without superuser rights gets "remaining connection slots are reserved for roles with the SUPERUSER attribute" as soon as only the reserved slots are left. "sorry, too many clients already" comes when every slot is taken. Neon's roles docs say roles created in the Console, CLI or API get neon_superuser membership with CREATEDB, CREATEROLE, BYPASSRLS and REPLICATION, which is not the SUPERUSER attribute, so your app role sees the first one. Postgres 16 changed the wording; older versions said "non-replication superuser connections".

Pooled and direct connection strings

Neon's pooled string is the direct one with -pooler added to the endpoint ID. The Neon Vercel integration sets DATABASE_URL to the pooled string and DATABASE_URL_UNPOOLED to the direct one. Neon's pooler runs PgBouncer in transaction mode, which does not support SET, temporary tables or SQL-level PREPARE, so schema migrations and pg_dump go through the direct string.

# direct: counts against max_connections
postgresql://user:password@ep-cool-darkness-123456.us-east-2.aws.neon.tech/dbname?sslmode=require

# pooled: up to 10,000 clients
postgresql://user:password@ep-cool-darkness-123456-pooler.us-east-2.aws.neon.tech/dbname?sslmode=require

One pool per instance with Fluid compute

Neon's Vercel guide and Vercel's connection pooling guide both create one pg Pool at module scope and pass it to attachDatabasePool from @vercel/functions, which closes idle connections before Vercel suspends the instance. A new Client in every request handler opens a connection per request instead.

import { Pool } from 'pg'
import { attachDatabasePool } from '@vercel/functions'

const pool = new Pool({ connectionString: process.env.DATABASE_URL })
attachDatabasePool(pool)

export async function GET() {
  const { rows } = await pool.query('select now()')
  return Response.json(rows[0])
}

Checklist

How to fix it, then check the fix

01Check the host in the DATABASE_URL your Vercel functions read: it should contain -pooler.
02Move client or pool creation out of the request handler to module scope, one pool per instance.
03Point migrations, pg_dump and tools that need session state at the direct string, such as DATABASE_URL_UNPOOLED.

Watch connections while you load the app, with the direct string:

select usename, count(*) from pg_stat_activity where datname = current_database() group by usename;

05Redeploy and send a burst of requests: they should succeed and the count should stay well below max_connections.

Sources

Official docs behind this checklist

More Vercel errors

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

Should I just raise the compute size?

A larger compute raises max_connections, 419 at 1 CU in Neon's table, but direct connections from many instances still grow with traffic. Use the pooler first.

Does the Neon serverless driver have this problem?

Neon's Vercel guide describes the @neondatabase/serverless HTTP driver as the option for classic serverless, and TCP with a pool as the lower-latency option with Fluid compute. Either way, avoid one direct connection per request.