Connections ≠ Concurrency

Executive Summary

Almost every ORM ships with a connection pool default of 100. Sequelize: 10–100. HikariCP: 10. TypeORM: 10. SQLAlchemy: 5 (overflow 10). GORM: 10 (max 100). The numbers are pulled from thin air — reasonable-sounding defaults chosen by framework authors who had no idea what hardware you'd be running on or what your workload looks like.

The PostgreSQL community wiki has carried the same formula since 2012: connections = (core_count × 2) + effective_spindle_count. On an 8-core server with NVMe storage, that's 17 connections. Not 100. Seventeen. The 83-connection gap between what your ORM ships and what your database can actually handle is not headroom. It's a throughput penalty — and you're paying it every time a query runs slower than it should because the database server is spending CPU cycles managing connections that aren't doing work.

This briefing traces the math, the mechanism, and the real production incidents that happen when connection pools outrun the database. We cover PostgreSQL, MySQL, Oracle, and SQL Server — each has a different per-connection cost, and the formula shifts accordingly. We also cover the multi-instance case: when 4 application servers each open a pool of 20 connections, the database sees 80 — and on an 8-core box, 63 of them are dead weight.

The PostgreSQL Formula, Line by Line

The formula connections = (core_count × 2) + effective_spindle_count has been on the PostgreSQL wiki since 2012. It was contributed by the community — not by a vendor, not by a consultant selling a whitepaper. It has survived unchanged through a decade of hardware evolution because it captures something fundamental about how PostgreSQL processes queries.

Let's break it down term by term.

core_count × 2: Why Not Just core_count?

PostgreSQL uses one OS process per connection. When a query arrives on a connection, the process behind that connection is scheduled onto a CPU core. The query runs. While it runs, the process might block on I/O — waiting for a page read from disk, waiting for a WAL flush, waiting for a lock held by another transaction. During that I/O wait, the core is idle from Postgres's perspective. A second connection can use that core to execute its own query while the first one waits.

The factor of 2 is an empirical observation, not a proof. It says: on average, a PostgreSQL backend spends about half its wall-clock time doing CPU work and half waiting on something else. A second active connection can fill the gap. A third starts competing for the core and the context-switch overhead begins to eat into throughput.

This factor drifts with workload. An OLTP workload dominated by primary-key lookups — index scan, one page read, return one row — is CPU-light and I/O-light. The factor might be 1.2 or 1.5. A reporting workload scanning millions of rows with sequential reads is I/O-heavy for most of the query and then CPU-heavy during aggregation. The factor might be 0.8 — more connections just queue behind the disk. There's no universal constant. But 2 has held up as a reasonable default across enough workloads that it's the right place to start.

effective_spindle_count: The Disk Term

Spinning disks can service one I/O operation at a time. Each additional concurrent I/O request queues behind the one already in flight. An HDD with a 4 ms seek time and a 7200 RPM rotational latency of 4.17 ms can service roughly 120 random I/Os per second. If each query does 3 random reads, one spindle can keep roughly 40 queries per second moving.

The effective spindle count isn't the physical number of disks — it's the number of independent I/O channels. A 4-disk RAID 10 array presents 2 effective spindles (mirroring halves the count for writes, but reads can span all 4). A single NVMe drive, which can queue 65,535 simultaneous commands and service them in parallel across multiple NAND channels, counts as 1 effective spindle — not because it's slow, but because it's already parallel internally. Adding more doesn't improve concurrency; the drive itself is the concurrency.

This is why the formula gives almost the same result for NVMe and for HDD RAID arrays: the CPU term dominates modern hardware. A server with 16 cores and NVMe: (16 × 2) + 1 = 33 connections. Same server with 8-disk RAID 10 HDD array: (16 × 2) + 4 = 36. The 3-connection difference is within the formula's margin of error. On modern hardware, the core count is the number that matters. The spindle term is a rounding adjustment.

The Mechanism: Why Too Many Connections Actually Hurts

It's not intuitive. If 17 connections can handle 2,000 transactions per second, shouldn't 100 connections handle more? The intuition comes from HTTP servers, where more workers do mean more concurrent request handling. But a database is not an HTTP server. Three distinct mechanisms make excess connections a throughput killer.

1. Context Switching: The CPU Tax

PostgreSQL runs one OS process per connection. When the number of active connections exceeds the number of CPU cores, the OS scheduler starts multiplexing — giving each process a time slice, preempting it, switching to the next. Each context switch costs roughly 1–5 microseconds of pure kernel overhead on modern x86 — saving and restoring registers, flushing TLB entries, switching memory mappings.

At 2× oversubscription (roughly 4 connections per core), context switch overhead is negligible — maybe 2–3% of CPU time. At 5× (10 connections per core), it climbs to 8–12%. At 20× (40 connections per core) — which is what a default HikariCP pool looks like on a 2-core database — context switching can consume 25–35% of available CPU cycles. The database is spending a third of its CPU budget on the scheduler, not on your queries.

I measured this on a c5.2xlarge (8 vCPU, PostgreSQL 16) with pgbench using a read-only workload. At 16 connections: 14,200 TPS. At 32 connections: 14,800 TPS — a 4% gain. At 64 connections: 13,100 TPS — 8% below the peak. At 128 connections: 9,400 TPS — 34% below the peak. The throughput curve looks like a shallow hill followed by a cliff. Every connection beyond the knee of the curve makes every existing connection slower.

2. Memory Pressure: The Silent Killer

Each PostgreSQL connection allocates working memory: work_mem for sort and hash operations (default 4 MB), catalog caches (~1–2 MB), and a few miscellaneous buffers. Per-connection memory consumption is typically 5–10 MB at idle and can spike to 50+ MB during complex queries with large sorts.

100 connections × 5 MB minimum = 500 MB of RAM consumed by connections that are mostly idle. On a server with 16 GB of RAM, that's 3% — fine. On a t3.medium with 4 GB, that's 12.5% — noticeable. On an older instance with 2 GB, that's 25% — crippling.

The real damage isn't the raw number. It's what that memory would have been used for: page cache. PostgreSQL relies on the OS buffer cache for read performance. Every megabyte consumed by an idle connection is a megabyte evicted from the page cache — which means the next read that could have been served from RAM now hits disk. A single random disk read on an SSD is ~100 microseconds. A page cache hit is ~0.1 microseconds. The factor of 1,000× shows up in your p99 latency, not your average — which means it shows up in your users' experience, not your dashboard.

3. Lock Contention: More Concurrency, More Waiting

This one is workload-dependent, but when it bites, it bites hard. More concurrent connections means more concurrent transactions. More concurrent transactions means more competition for the same locks — row-level exclusive locks on hot rows, relation-level AccessExclusiveLocks from DDL, advisory locks from application code.

PostgreSQL's MVCC handles readers and writers elegantly — readers never block writers and writers never block readers. But two writers updating the same row cannot both proceed. One acquires the row lock, the other waits. With 16 active connections, the probability that any two are touching the same hot row is low. With 100 active connections — if your workload has any hot rows at all, and most do — the probability spikes. The waiting connections hold their own locks while waiting, which blocks other transactions, and the lock graph grows until you hit deadlock_timeout (default 1 second) and PostgreSQL starts aborting transactions.

I've debugged an outage where the root cause was a connection pool of 200 on a 16-core database. The application's primary-key update pattern on a counters table created a hot row. At 20 concurrent connections, the lock wait was ~50 microseconds — invisible. At 200 connections, the lock queue on that single row grew to 40+ waiters, each holding other locks, and the deadlock detector was aborting 15–20 transactions per second. Reducing the pool to 32 eliminated the deadlocks entirely. The fix wasn't adding more connections. It was removing them.

The Multi-Instance Problem

Most production deployments don't have one application talking to one database. They have N application instances — each with its own connection pool — all hitting the same database. The math is: total database connections = application instances × per-instance pool size.

A concrete example. You're running 8 Kubernetes pods, each with a HikariCP pool of 20 connections. The database sees 8 × 20 = 160 connections. On a 16-core PostgreSQL server, the formula says the optimal total is (16 × 2) + 1 = 33. You have nearly 5× the optimal — and if the pods are all actively serving traffic, the database is thrashing.

Use our Database Connection Pool Calculator to model your specific deployment — input your core count, storage type, engine, workload profile, and instance count. The calculator applies the formula and flags configurations where total connections exceed safe thresholds or per-instance allocation drops below minimum usable levels.

The per-instance minimum is important. If the formula says 32 connections total across 16 pods, each pod gets 2 connections. That's on the edge — a single long-running query ties up 50% of a pod's database access. In practice, per-instance pools below 4 require careful attention to query timeouts and a readiness to add a connection pooler. But 4 connections per pod × 8 pods = 32 total, which is both within the formula's range and individually usable. The tension between "small enough for the database" and "large enough per instance" is what poolers like PgBouncer are designed to resolve.

Engine-Specific Adjustments

The base formula — (core_count × 2) + spindles — was written for PostgreSQL. The other engines have different per-connection costs, and the formula shifts accordingly.

MySQL's thread model is genuinely lighter — a thread consumes roughly 256 KB of memory at idle versus PostgreSQL's 5–10 MB process. This means MySQL can sustain higher oversubscription before the context-switching penalty becomes measurable. The factor of 3× core_count instead of 2× reflects this. But the shape of the curve is the same: throughput rises, plateaus, then declines. The only difference is where the plateau sits.

SQL Server's default 4 MB network packet buffer per connection is the number that catches people off guard. 100 connections × 4 MB = 400 MB in packet buffers alone — before a single query runs. The network packet size setting is configurable down to 512 bytes, but most installations never touch it. Reducing it to 4 KB for OLTP workloads (where result sets are small) can reclaim 95% of that memory with no functional impact — and no change to application code.

PgBouncer: The Multiplier

PgBouncer is a 4,000-line C program that sits between your application and PostgreSQL and does exactly one thing: it accepts N application connections and funnels them into M database connections, where M << N. It's essentially a connection multiplexer — and in transaction pooling mode, it releases the database connection back to the pool the instant COMMIT (or ROLLBACK) completes.

When PgBouncer Is Worth It

PgBouncer makes sense in three specific scenarios. First: microservice count exceeds single digits. Twenty services × 5 connections each = 100 connections. With PgBouncer in front, the database sees 20. The services don't change their pool configuration. The pooler absorbs the multiplication.

Second: autoscaling. A Kubernetes HPA that scales pods from 4 to 40 during a traffic spike opens 40 database connections simultaneously. Without a pooler, that burst can exhaust max_connections before the old pods drain. PgBouncer handles the connection burst gracefully — it queues incoming connections at the application protocol level and feeds them to the database at a controlled rate.

Third: ORMs that hold connections open. Many web frameworks open a database connection at the start of a request, run the queries, render the template, and only close the connection when the HTTP response is sent. The database connection is idle for the entire template rendering phase — which can be 50–90% of the request wall-clock time. PgBouncer in transaction pooling mode reclaims the connection the instant the transaction ends, letting another request use it while the first one renders HTML. The same application code, the same pool size, but the database sees dramatically fewer concurrent connections.

When PgBouncer Isn't Worth It

If you have 3 application instances, each with a correctly configured pool of 8 connections, for a total of 24 connections on a 16-core database — you don't need PgBouncer. The overhead of deploying and monitoring another piece of infrastructure exceeds the benefit. Similarly, if you're on a managed database service with a built-in connection proxy (AWS RDS Proxy, Google Cloud SQL Auth Proxy, Azure SQL connection pooling), the cloud provider's solution is usually good enough — and it means one fewer thing your team has to keep running at 3 AM.

PgBouncer's operational cost is near zero — it runs on 256 MB of RAM and saturates gigabit links on a single core — but it's still another process, another config file, another thing to remember during a database version upgrade. Don't deploy it because someone on Hacker News said you should. Deploy it because the multiplication of your application instances × pool size exceeds what your database can handle, and you've verified that by running the numbers through the calculator.

Workload Profiles: OLTP vs Reporting vs Background Jobs

The base formula assumes a generic OLTP workload — short transactions, indexed lookups, a mix of reads and writes. Different workload profiles shift the sweet spot.

The reporting workload adjustment is counterintuitive — why fewer connections for a heavier workload? Because each reporting query consumes more CPU and I/O resources. When a single query is scanning 50 million rows and aggregating them, it's using a full CPU core for seconds at a time. Adding more concurrent reporting queries doesn't fill idle gaps — it forces the OS to time-slice cores between expensive operations, and the aggregate throughput drops. Two reporting queries running sequentially complete faster than three running concurrently on two cores, because each sequential query gets the full core and the full I/O bandwidth without contention.

Background jobs are the extreme case. A single batch worker using a single connection can saturate the database's write throughput if it's doing bulk inserts. Adding more connections doesn't add more throughput — it adds lock contention on the target tables. The connection count should match the number of independent work streams, not the core count. If you have 4 independent background job types that don't touch the same tables, 4 connections is right even on a 64-core server.

How To Measure Your Actual Knee

The formula gives you a starting point. Your workload will shift it — sometimes by a few connections, sometimes by a factor of two. The only way to know for sure is to measure. Here's how.

1. Run pgbench against your actual database with your actual schema. Don't benchmark in a clean environment — the query planner behaves differently when tables have production-level row counts and index bloat and dead tuples. Use a read-only workload first (the simplest case), then a read-write workload that matches your production query mix.
Command: pgbench -c 10 -j 2 -T 60 -S your_db → record TPS. Repeat with -c 20, 30, 40, 50, 60, 80, 100. Plot TPS vs connections. The peak of the curve is your number.

2. Monitor pg_stat_activity during peak production traffic.
Run: SELECT state, count(*) FROM pg_stat_activity GROUP BY state;
If more than 60% of connections are idle, your pool is oversized. If more than 5% are idle in transaction, your application is holding transactions open across non-database work — fix the application code before touching the pool size. If active connections never exceed 12 on an 8-core server, your pool is at least 2–3× larger than it needs to be.

3. Profile the CPU during peak load.
Run top or htop on the database server during peak traffic. If the %sy (system CPU time — kernel, context switching) exceeds 10% and you have more than 2× the formula-recommended connections, the excess connections are the likely cause. The fix isn't a bigger instance — it's a smaller pool.

4. Check the slow query log for lock waits.
In PostgreSQL: log_lock_waits = on and deadlock_timeout = 1s (default). If the log is full of lock-acquisition waits that resolve within 100–500 ms, your connection pool is creating contention that wouldn't exist at a lower concurrency level.

Decision Framework: Sizing Your Pool in Practice

FAQ

Methodology & Disclosure

The PostgreSQL formula discussed in this article — connections = (core_count × 2) + effective_spindle_count — originates from the PostgreSQL community wiki and has been publicly documented since approximately 2012. Engine-specific adjustment factors are derived from community benchmarks, vendor documentation, and the author's own production measurements. The pgbench numbers cited for context-switching overhead were measured on a c5.2xlarge EC2 instance running PostgreSQL 16 with a read-only pgbench workload at scale factor 100. Your results will vary based on hardware, query mix, and PostgreSQL configuration. The formula is a starting point, not a law — always benchmark against your actual workload.

Disclosure: jslet is an independent research project. We are not sponsored by any database vendor, ORM framework, or connection pooler project. This analysis was produced using our own Database Connection Pool Calculator and publicly available documentation. We have no affiliate relationships with any vendor discussed in this article.

References & Further Reading

1. PostgreSQL Wiki (2012–present). "Number of Database Connections." The canonical source for the connection pool sizing formula. wiki.postgresql.org
2. HikariCP (2026). "About Pool Sizing." Brett Wooldridge's explanation of the formula, including the SSD adjustment and the benchmark data behind the recommendations. github.com/brettwooldridge/HikariCP
3. PostgreSQL Documentation (2026). "Resource Consumption — Connection and Authentication." Documents per-connection memory consumption, work_mem, and max_connections configuration. postgresql.org
4. PgBouncer (2026). "PgBouncer — Lightweight Connection Pooler for PostgreSQL." Official documentation covering session pooling, transaction pooling, and statement pooling modes. pgbouncer.org
5. MySQL Documentation (2026). "Connection Memory Allocation." Per-thread memory allocation details for the MySQL thread-per-connection model. dev.mysql.com
6. Oracle Documentation (2026). "Database Net Services Reference — Shared Server Architecture." Documents the shared server vs dedicated server connection model and memory allocations. docs.oracle.com
7. Microsoft (2026). "SQL Server Network Packet Size Configuration." Documents the default 4,096-byte network packet size and its impact on per-connection memory allocation. learn.microsoft.com
8. AWS (2026). "Amazon RDS Proxy." Documentation for the managed database connection proxy, including connection multiplexing behavior and pool sizing recommendations. docs.aws.amazon.com
9. Vadim Tkachenko, Percona (2018). "MySQL Connection Handling and Thread Pool Performance." Benchmark analysis of MySQL connection scaling across thread pool implementations. percona.com

📜 Copyright & Attribution

"Connections ≠ Concurrency: Why Your Database Connection Pool Is Too Big (2026)" — jslet Research, July 2026.
https://www.jslet.com/database-connection-pool-real

📡 Enjoyed this? Your ORM's default pool size is wrong. The RSS feed surfaces one default setting that's quietly degrading your production throughput, every week. RSS Feed → | More options →