What’s the Optimal Database Connection Count? A Data‑Driven Study

Problem Background

Existing services often configure a large number of database connections per instance, which creates unnecessary overhead for each long‑lived connection and puts pressure on the database server. As services scale and are split into more instances, this can become a stability risk. A standard for the optimal connection pool size is therefore required.

Scientific Method

1. Problem

What is an appropriate number of database connections for a typical application?

2. Hypothesis & Prediction

Industry experience suggests that 8–10 connections are typical. The hypothesis is that reducing the pool from 100 to 10 connections will not noticeably degrade response time or throughput, assuming the connection count is not a bottleneck.

3. Experiment

3.1 Single‑Interface Load Test

Setup : 20 000 concurrent requests were generated using a thread pool. Two runs were performed – one with 100 threads (100 connections) and one with 10 threads (10 connections).

Result : 100 threads completed the workload in 39 seconds; 10 threads completed it in 35 seconds, indicating no performance loss with the smaller pool.

3.2 Link‑Level Load Test

Result : When the connection count was ≤10, throughput slightly improved and no degradation was observed.

3.3 Detailed Scenario Data

Scenario 1 : 100 threads started at 2024-04-25T23:23:53.481Z and finished at 2024-04-25T23:24:32.003.

Scenario 2 : After restarting the service, 10 threads started at 2024-04-25T23:28:00.172Z and finished at 2024-04-25T23:28:35.430.

Scenario 3 : With 70 threads and a maximum thread pool of 300, throughput was ~238 ops/s; with a max pool of 10, throughput rose to ~288 ops/s; with a max pool of 5, throughput reached ~329 ops/s. Excess threads remained idle and did not improve throughput.

4. Analysis

4.1 Theoretical Analysis

Database connections represent concurrency and are closely tied to CPU core count. For a typical production server (4 CPU × 8 GB RAM), the optimal number of connections depends on the proportion of time spent in DB operations.

For CPU‑bound workloads, a common rule of thumb is: connections = CPU_cores + 1 Thus, a 4‑core machine would use 5 connections.

For I/O‑bound workloads, the formula is:

threads = CPU_cores × targetCPUUtil × (1 + waitTime / computeTime)

Using measured DB read/write latency of <1 ms, 8 CPUs, target utilization of 0.6, and assuming waitTime ≈ computeTime, the calculation yields roughly 8 connections, confirming that a pool size of ≤10 is reasonable.

Modern database servers equipped with SSDs and large memory (e.g., 16 CPU × 32 GB) further reduce latency, making the workload more CPU‑bound and still supporting a ≤10 connection recommendation.

4.2 Load‑Test Analysis

The empirical tests show that keeping the connection pool at 10 or fewer does not degrade performance; in fact, throughput improves slightly, validating the hypothesis.

Conclusion

Setting the connection pool to 10 connections per instance enables a single machine to achieve >500 TPS, satisfying typical production requirements. New applications should default to this value and adjust only after further load‑testing if needed.

Summary

Overly large database connection pools can harm performance by consuming resources without increasing throughput. A default of ten connections per instance provides sufficient concurrency for most workloads while avoiding unnecessary overhead.