Why do I get FATAL: too many connections?

Each running app instance keeps a pool of open connections to the database. Total demand is instances times pool size. If that plus the connections reserved for superusers, migrations, and other clients exceeds the database max_connections, new connections are refused with that error - often during a deploy when old and new instances overlap and demand briefly doubles.

How big should each pool be?

Smaller than people expect. A pool only needs enough connections to cover concurrent in-flight queries per instance, which is usually single digits - more connections do not mean more throughput once the database CPU is busy. Size the pool so instances times pool size, plus reserved, stays comfortably under max_connections, and use a pooler like PgBouncer if you need many instances.

During a rolling deploy, old and new instances run at the same time, so connection demand can nearly double for a few seconds. Migrations, admin tools, and background workers also need connections. Leaving headroom - this tool flags anything over about 80 percent of available - keeps those overlaps from tipping you into refused connections.

Free tool · Runs in your browser

Connection pool sizer.

Size your database pool so you never hit FATAL: too many connections. Enter your numbers and see total demand, headroom, a clear verdict, and a safe pool size — including the deploy-overlap spike that catches people out.

Database max_connections

Postgres default is 100

Reserved connections

superuser, migrations, admin tools

App instances

processes / pods / dynos

Pool size per instance

max connections each instance opens

Account for rolling-deploy overlap (demand ~doubles briefly)

—

The error that only shows up under load

Connection exhaustion is a classic production surprise: everything is fine in testing with one instance, then you scale to six, a deploy briefly runs twelve, and the database starts refusing connections. The math is simple but easy to skip — instances times pool size, plus what is reserved, has to fit under max_connections with room for the deploy overlap. Sizing the pool down (and reaching for a pooler when you have many instances) is almost always the fix, because a pool far larger than your concurrent queries buys nothing.

Related free tools

Production-ready checkerScore your deploy Deploy error decoderDecode any deploy error CORS config generatorFix CORS the right way Cache-Control builderBuild a Cache-Control header

All free tools →

Free tools for the backend you run.

One of a set of free developer tools from Infraveil — the control plane for running, securing, and watching your backend on servers you own. Pairs with the capacity calculator and DATABASE_URL builder.

See all free tools

Get the backend toolkit

Practical tools and guides for shipping and running a backend you own. No spam.