{"post":{"slug":"connection-limits-explained-2026","title":"Connection Limits: Why More Connections Make Things Slower","excerpt":"Raising the connection limit to handle load usually makes throughput worse. Each connection costs memory and scheduling, and past a point the database spends its time coordinating.","category":"code","date":"January 16, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">T</span>he application is under load, connections are exhausted, and errors are appearing. The obvious fix is to raise the connection limit.\n\nDo that and throughput frequently gets worse. The errors change from connection failures to slow queries, which is a less obvious problem and a harder one to diagnose.\n\n## What changed in 2026\n\n- **Serverless architectures made this acute.** Function-per-request models opening connections independently exhausted limits routinely.\n- **Poolers became mandatory rather than advisable.** Running without one stopped being viable at any real scale.\n- **Small-pool guidance held up.** The counterintuitive finding that fewer connections serve more throughput continued to be confirmed.\n- **Pooler placement got attention.** Where the pooler sits — in the application, as a sidecar, or as a separate service — became a considered decision.\n\n## Why more is worse\n\nA database serving connections is not like a web server. Each connection consumes resources whether or not it is active, and active connections contend for the same finite hardware.\n\n**Fixed memory per connection.** Every connection has associated memory for its state, buffers, and query workspace. Hundreds of connections consume that hundreds of times, and that memory is not available for caching data.\n\n**Contention.** Concurrent connections compete for locks, buffers, and internal structures. Coordination overhead grows faster than linearly with concurrency.\n\n**CPU and I/O are finite.** Twenty connections executing queries on eight cores are already oversubscribed. Two hundred do not get more work done — they get the same work done with far more context switching.\n\nThe result is a throughput curve that rises, peaks, and then *falls*. Past the peak, adding connections reduces total work completed while increasing every individual query's latency.\n\n| Connections | Throughput | Latency |\n| --- | --- | --- |\n| Very few | Below capacity | Low |\n| Near optimal | Peak | Low |\n| Well above optimal | Falling | Rising sharply |\n| Far above optimal | Poor | Very high |\n\n## Pool sizing\n\nThe common error is sizing the pool to application concurrency: a thousand concurrent requests, so a thousand connections.\n\nThe right basis is what the database can serve well, which is a much smaller number related to available cores and the storage's ability to service concurrent I/O. It is frequently in the low tens even for substantial hardware.\n\nRequests beyond that queue at the pool. That sounds bad and is far better than the alternative: a queued request waits and then executes quickly, whereas an admitted request in an oversubscribed database executes slowly and makes everyone else slower too.\n\nQueueing at the pool converts contention into an orderly wait, which is the whole point — see [connection pooling explained](/blog/connection-pooling-explained-2026).\n\nFind the number empirically. Load test at increasing pool sizes and watch where throughput peaks; that is your size, and it is usually smaller than expected.\n\n## Idle connections are not free\n\nAn idle connection still holds its memory allocation. A large pool of mostly-idle connections consumes memory that would otherwise cache data.\n\nWorse, an idle connection *inside a transaction* holds locks and blocks cleanup across the database — the single most damaging connection state, per [MVCC explained](/blog/mvcc-explained-2026). Bounding it with an idle-in-transaction timeout matters more than the connection count itself.\n\nThe serverless case deserves specific mention: a platform scaling to hundreds of concurrent function instances, each opening its own connection, exhausts limits immediately. A pooler between them is not optional there — it is what makes the architecture work at all.\n\n## Common mistakes\n\n- **Raising the limit to fix exhaustion.** Trades one problem for a worse one.\n- **Sizing the pool to application concurrency.** Wrong basis entirely.\n- **No pooler in a serverless architecture.** Guaranteed exhaustion.\n- **Ignoring idle-in-transaction connections.** The most damaging state.\n- **Not load testing pool size.** The optimum is smaller than intuition suggests.\n- **Several application instances each with a large pool.** The total is what the database sees.\n- **Forgetting reserved connections.** Leave headroom for administrative access during an incident.\n\n## FAQ\n\n**How do I find the right pool size?**\nLoad test at several sizes and find where throughput peaks. Start lower than you expect; the peak is frequently at a surprisingly small number.\n\n**What if requests queue at the pool?**\nThat is the design working. A brief queue with fast execution beats immediate admission with slow execution. Monitor queue wait time, and if it is consistently high you need more database capacity rather than more connections.\n\n**Does pooling mode matter?**\nConsiderably. Transaction-mode pooling multiplexes far more effectively and breaks session-scoped features — see [connection pooling explained](/blog/connection-pooling-explained-2026).\n\n**Should I reserve connections?**\nYes — keep headroom so an administrator can connect during an incident. A database at its connection limit that you cannot log into is a much worse incident.\n\n## Where to go next\n\nFor pooling mechanics and modes, read [connection pooling explained](/blog/connection-pooling-explained-2026). For bounding idle transactions, [statement timeouts](/blog/statement-timeouts-explained-2026), and for the cleanup they block, [autovacuum tuning](/blog/autovacuum-tuning-2026).","hue":300,"metaTitle":"Connection Limits: Why More Connections Are Slower","metaDescription":"Why database throughput falls as connection count rises, what each connection costs, and why pooling rather than raising limits is the answer.","keywords":["connection limits","max connections","connection pooling sizing","database contention","too many connections","throughput saturation","pool sizing","database operations 2026"],"tldr":["**Throughput peaks well below the connection limit** — beyond it, contention dominates.","**Each connection has fixed memory cost** — regardless of whether it is doing anything.","**Raising the limit is usually the wrong fix** — a pooler is the right one.","**Idle connections still consume resources** — and hold locks if they are mid-transaction.","**Skip:** sizing the pool to your application's concurrency. Size it to what the database can serve well."],"readTime":"4 min read","wordCount":823},"related":[{"slug":"connection-pooling-explained-2026","title":"Connection Pooling Explained in 2026","excerpt":"Opening a database connection is not free. Connection pooling reuses open connections instead of paying that cost every request - here is how pools work and how to size one.","category":"code","date":"July 1, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":320},{"slug":"pgbouncer-explained-2026","title":"PgBouncer Explained 2026: How Postgres Pooling Works","excerpt":"PgBouncer sits between your application and Postgres, multiplexing many client connections onto a small number of real database connections. Here is exactly how it does that, and which pool mode to pick.","category":"code","date":"August 7, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":316},{"slug":"statement-timeouts-explained-2026","title":"Statement Timeouts: Stopping a Query Before It Stops You","excerpt":"One query scanning a huge table can hold resources long enough to degrade everything else. A statement timeout turns that into an error instead of an incident.","category":"code","date":"January 21, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":312}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"chatgpt-vs-claude-vs-gemini-2026","title":"ChatGPT vs Claude vs Gemini in 2026: which one should you actually pay for?","excerpt":"All three are excellent. They're also genuinely different. Here's an honest, use-case-by-use-case comparison after six months of daily use.","category":"ai","date":"January 16, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":210},"older":{"slug":"contractor-vetting-guide-2026","title":"Vetting a Contractor: Questions Before Money Changes Hands","excerpt":"The expensive mistakes in home work are made before anyone picks up a tool — a large deposit, no written scope, and no verification that the person is who they say they are.","category":"guides","date":"January 16, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":170}}