Neon PgBouncer runs transaction mode: know the unsupported list

The pooler's transaction mode and what it forbids

The trap

pool_mode=transaction means the server-side connection is reassigned after every transaction. Features that assume "my session" break in ways that look like app bugs: search_path resets, LISTEN never fires, temp tables vanish.

The rule: the unsupported list (from Neon's docs)

Not supported with pooled connections:

• SET / RESET (session variables)
• LISTEN / NOTIFY
• WITH HOLD cursors
• PREPARE / DEALLOCATE
• Temporary tables with ON COMMIT PRESERVE ROWS / DELETE ROWS quirks
• LOAD
• Session-level advisory locks

Limits to know

• max_client_conn: 10,000 client connections to PgBouncer; beyond that clients get "no more connections allowed".
• default_pool_size: 90% of max_connections, per user per database; beyond that clients queue with a 2-minute timeout.
• max_connections: direct-to-Postgres limit by compute size; beyond it "too many clients already".

Checklist

• Hitting any item on the unsupported list: switch that workload to the direct connection string.
• Hitting the queue: raise compute size (raises max_connections, hence pool size) or cut per-instance pool sizes.
• Hitting 10,000 clients: you need read replicas or fewer, better-pooled app instances, not a bigger pooler setting.

Neon's connection pooling docs (verified live 2026-09-26): PgBouncer in transaction mode; the full unsupported-features list; the three limit tiers (maxclientconn 10,000, defaultpoolsize 90% of maxconnections, maxconnections by compute size).