RDS "FATAL: too many connections": how to respond

TL;DR

Too many connections means connection demand exceeds maxconnections: too many app instances, oversized pools, or leaked connections. Respond in order: stop the bleeding (restart the worst offenders to free connections), find the demand source (which hosts hold the connections), then fix structurally (pool sizing, PgBouncer, or a reasoned maxconnections increase). Raising max_connections without fixing demand just moves the crash later.

The query

RDS "FATAL: too many connections": how to respond

Use this when

• Applications fail with FATAL too many connections
• The database rejects new connections
• Deciding whether to raise max_connections
• After scaling app instances

Not for when

• Slow queries (tune those separately)
• Connection timeouts (different error)
• Replication lag

Steps

Step 1: Stop the bleeding

Identify and restart the worst connection hogs (leaked pools, runaway workers) to free connections immediately. This is triage, not the fix; it buys the time to diagnose. Expected output: connections freed; new connections succeeding again.

Step 2: Find who holds the connections

Query the database's connection stats grouped by client host and application name. The distribution names the demand source: usually one service with an oversized pool or a leak. Expected output: the top connection consumers identified by host and app.

Step 3: Fix pool sizing on the hogs

Reduce max pool sizes to match real concurrency needs, and set connection timeouts so idle connections do not accumulate. Most pools are sized by guess; size them from measured demand. Expected output: per-service pools sized deliberately, total under the database limit with headroom.

Step 4: Add PgBouncer for structural relief

For many app instances, put PgBouncer in transaction pooling mode between apps and RDS. It multiplexes thousands of app connections onto dozens of database connections, which is the durable fix for connection-count scaling. Expected output: database connection count decoupled from app instance count.

Step 5: Raise max_connections only with math

If you raise the limit, account for per-connection memory overhead against instance RAM. An unjustified increase trades connection errors for OOM crashes, which are worse. Expected output: the limit set from memory math, not from hope.

Provenance

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