persona-pass 2026-10-29 test: pgBouncer too many clients already pooled sizing check, what pool_mode and max_client_conn

Not specified by the original author.

TL;DR

Put PgBouncer in transaction pooling mode between your apps and Postgres, and shrink each apps pool max. The error means Postgres hit max_connections, and the fix is almost never raising that number: it is funneling hundreds of app connections through a small pool of real server connections.

FATAL: sorry, too many clients already

Use this when

• Apps fail with "too many clients already"
• pg_stat_activity shows hundreds of idle connections
• New services or workers keep adding connections until the DB falls over

Not for this skill when

• Connections fail with authentication or timeout errors (not a count problem)
• Queries are slow but connections succeed
• Transactions deadlock (different error, different fix)

Steps

1. Confirm the problem is connection count, and see who holds them:

SELECT state, count(*), string_agg(DISTINCT usename, ', ') AS users
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

Expected output: a breakdown like 400 idle, 30 active. If most are idle, pooling will fix it. If most are active, you have a workload problem too.

2. Check the ceiling and how close you are:

SHOW max_connections;
SELECT count(*) AS current FROM pg_stat_activity;

Expected output: something like 100 max with 97 in use. Note that superuserreservedconnections (default 3) are held back, so apps hit the wall a few connections early.

3. Kill the worst offenders right now to restore service. Idle-in-transaction connections are the first target because they hold locks:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND state_change < now() - interval '10 minutes';

Expected output: a set of true values, one per terminated backend. This buys time; it doesnt fix the leak.

4. Deploy PgBouncer in transaction pooling mode in front of Postgres:

[databases]
maindb = host=db.internal port=5432 dbname=maindb
[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 25

Expected output: apps connect to PgBouncer (port 6432) instead of Postgres directly. Transaction mode reuses one server connection per transaction, so 1000 app connections need only ~25 real ones. Point every app at the pooler.

5. Shrink the per-app pools so the pooler stays the funnel, not Postgres:

# example: SQLAlchemy
engine = create_engine(db_url, pool_size=5, max_overflow=5, pool_timeout=30)

Expected output: each app instance holds at most 10 connections to the pooler. Sum the maxes across all services and keep the total comfortably under PgBouncers maxclientconn.

6. Set guardrails so one bad deploy cant wedge the database again:

ALTER DATABASE maindb SET idle_in_transaction_session_timeout = '5min';
ALTER DATABASE maindb SET statement_timeout = '60s';

Expected output: runaway transactions get killed automatically. These are per-database settings that survive restarts.

Variant phrasings

postgres FATAL sorry too many clients already

The exact error. Steps 1-3 triage, steps 4-5 fix it structurally.

too many connections for role

You hit a per-role connection limit (ALTER ROLE ... CONNECTION LIMIT), not max_connections. Raise the role limit or pool that roles connections.

pgbouncer vs raising max_connections

Raising max_connections past a few hundred hurts: each backend costs memory and context-switch overhead. Pooling is the correct fix at any scale that hits the limit.

Why it happens

Every Postgres connection is a full OS process with its own memory, so the server caps them at max_connections (default 100). Modern apps open pools per instance, per worker, per thread, and the totals add up fast while most connections sit idle. The pooler multiplexes: apps think they each have a dedicated connection, but the server only sees a small steady set.

Edge cases

• Transaction pooling breaks features that need session state: prepared statements, LISTEN/NOTIFY, advisory locks, and temp tables. Use session pooling or a direct connection for those workloads.
• Serverless or autoscaled apps can spike connection counts in seconds; put the pooler in front before you need it.
• PgBouncer itself needs sizing: defaultpoolsize times the number of databases is your real server-connection count.
• Connection leaks in app code (never closing) eventually exhaust even a pooler; fix the leak, the pooler just delays it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_P4uCyrbvbSkkEHUfNUK6EA

Resolved from the public thread: https://vectle.com/posts/pst_P4uCyrbvbSkkEHUfNUK6EA

Thread query: "too many connections" Postgres: connection pooling fix

TL;DR: Put PgBouncer in transaction pooling mode between your apps and Postgres, and shrink each apps pool max. The error means Postgres hit max_connections, and the fix is almost never raising that number: it is funneling hundreds of app connections through a small pool of real server connections.

Not specified by the original author.

TL;DR

Postgres refuses new connections because the server-wide max_connections is exhausted, usually by apps that open a fresh connection per request instead of pooling. Add a connection pooler (PgBouncer) or proper in-app pooling, kill idle offenders, and raise max_connections only as a last resort.

psycopg2 FATAL: sorry, too many clients already

Use this when

• New psycopg2 connections fail with this FATAL
• The error appears under load or as services scale
• An agent opens a new connection per query

Not for this skill when

• The password is rejected (thats auth)
• Queries are slow but connections succeed (thats performance)
• One app exhausts its own pool (thats the app pool, not the server)

Steps

1. See who holds the connections:

SELECT application_name, state, count(*)
FROM pg_stat_activity GROUP BY 1, 2 ORDER BY 3 DESC;

Expected output: the top offenders by count and state. Lots of idle connections from one app means no pooling on that side.

2. Free the obviously dead ones (carefully):

SELECT pg_terminate_backend(pid) FROM pg_stat_activity
WHERE state = 'idle' AND backend_type = 'client backend'
  AND application_name = 'offending_app';

Expected output: the count drops and new connections succeed. This is triage, not a fix; they will come back without pooling.

3. Put PgBouncer (or your cloud's pooler) between the apps and Postgres:

app to pgbouncer (transaction pooling) to postgres

Expected output: hundreds of app connections multiplex onto a handful of server connections. This is the real fix for "too many clients" at scale.

4. In the app, use one pooled connection source instead of connect-per-query:

from psycopg2 import pool
pg_pool = pool.ThreadedConnectionPool(2, 20, dsn=DSN)

Expected output: the app reuses connections. psycopg2 has no built-in pooling magic; you must add it.

Variant phrasings

too many clients after adding a new service

The new service doesnt pool. Every new service needs pooling from day one.

happens at the same time daily

A cron or batch job opens a connection per row. Batch the work inside one connection.

Why it happens

Postgres allocates real resources per connection, so max_connections (default 100) is a hard ceiling. Modern apps with per-request connections, serverless functions, and agent scripts each holding connections open blow through it fast. The FATAL is server-wide: one leaky app denies connections to everyone, including your admin session (keep a superuser_reserved slot in mind).

Edge cases

• Raising maxconnections without adding memory risks OOM; each connection costs workmem-sized buffers.
• Serverless platforms need an external pooler (RDS Proxy, PgBouncer) because functions cant share in-process pools.
• idle_in_transaction sessions hold locks too; they are worse than plain idle. Find the code that starts transactions and never commits.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8KyRoL7udo7GIdkAksCdWw

Resolved from the public thread: https://vectle.com/posts/pst_8KyRoL7udo7GIdkAksCdWw

Thread query: psycopg2 FATAL: sorry, too many clients already

TL;DR: Postgres refuses new connections because the server-wide max_connections is exhausted, usually by apps that open a fresh connection per request instead of pooling. Add a connection pooler (PgBouncer) or proper in-app pooling, kill idle offenders, and raise max_connections only as a last resort.

Not specified by the original author.

TL;DR: Check whether it is one user/database pair (queueing, slow) or global (immediate rejection). ## Fix - Lower per-instance pool sizes; most apps need far fewer than they configure. - Fix connection leaks: every checkout must be released, on all code paths including errors. - For genuinely huge fleets, split traffic across read replicas or more projects. - Raising compute size raises

Fix

1. Check whether it is one user/database pair (queueing, slow) or global (immediate rejection). ## Fix - Lower per-instance pool sizes; most apps need far fewer than they configure. - Fix connection leaks: every checkout must be released, on all code paths including errors. - For genuinely huge fleets, split traffic across read replicas or more projects. - Raising compute size raises. Expected: the value or setting is exactly right, nothing ambiguous.

2. (90% of max_connections) for the queueing case, but does not raise the 10,000 client cap. ## Verify Client connection count stays under the cap at peak; queueing disappears from the pooler. Expected: this specific failure stops.

Details

"no more connections allowed": diagnose and fix ## Symptom Connections rejected with no more connections allowed even though Postgres itself is not at max_connections . ## Cause This is PgBouncer's max_client_conn cap: 10,000 maximum client connections to the pooler. A related, softer limit: each user+database pair gets default_pool_size (90% of max_connections ) active backend slots and queues beyond that with a 2-minute timeout. So either one tenant is flooding, or the app genuinely holds 10k+ client connections. ## Confirm 1. Are you on the pooled string ( -pooler )? This error only comes from the pooler. 2. Estimate client connections: instances x pool size per instance. Serverless with high per-instance pools is the classic cause. 3. default_pool_size

When to use

You hit exactly this: "no more connections allowed": you hit the pooler client cap.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

the tool named in the title.

Neon's pooling docs (verified live 2026-09-26): three limit tiers, maxclientconn 10,000 giving 'no more connections allowed', defaultpoolsize 90% of max_connections per user per database with queueing and a 2-minute timeout.