Why did APIs get slower after increasing the database connection pool, and what is the appropriate connection count?

APIs became slower after the database connection pool was enlarged. In most cases, the pool is not too small. Slow queries, long transactions, or connection leaks are holding connections for a long time, and adding more connections only increases lock contention and scheduling overhead on the database side. Connection pool size has no fixed value. Measuring first and then adjusting is the more common practice in 2026 project deliveries: observe the number of connections the application holds concurrently at peak time and the time a single operation holds a connection, then estimate the initial range. The experience ranges are 10-30 connections for small internal systems and 50-100 for typical online services. If you tune it above 200 and it remains fully occupied for a long time, prioritize investigating SQL and connection release instead of continuing to increase the value.

Why do APIs become slower after the connection pool is enlarged?

Each connection in the pool is a session that the database must maintain. When the connection count is too high, the database spends a large amount of time on thread scheduling, lock waits, and context switching. Response time for a single query may increase, and overall throughput may drop instead. When the business side sees an error saying 'not enough connections', the root cause is often that connections are not released in time, not that pool capacity has reached its physical limit.

A common operation in projects is raising the connection count directly from 50 to 500. The result is a spike in database threads, multiplied row lock and gap lock waits, and slower APIs. This misconception comes from mixing a capacity issue with a performance issue.

• The more connections there are, the higher the database session and thread scheduling overhead;
• The longer long transactions hold connections, the more total occupied connections increase;
• If connection leaks exist, no matter how large the pool is adjusted, it will eventually be fully occupied again.

What connection pool tuning really needs to balance is the probability of request waiting and the upper limit of database concurrency; it is not a linear 'the larger, the better' relationship.

If the pool is too small or too large, which problem appears first?

If the pool is too small, the first sign is that available connections are used up and requests enter a waiting queue. If the wait exceeds the configured acquisition timeout, callers receive a connection acquisition failure. At this point database load is often not high, so backend processing capacity is wasted.

If the pool is too large, active database connections keep rising. Databases usually do not reject new connections, but internal lock contention and context switching intensify. Common symptoms include longer database response time, higher CPU, and more slow queries on the application side.

To judge whether the pool is sufficient, do not only check whether errors occur; check whether the active connection count frequently hits the ceiling. Common signals are:

• Logs report connection acquisition timeouts but database CPU is low: the pool may be too small or the acquisition wait timeout may be too short;
• Active connections remain near the maximum while slow SQL grows: optimize slow operations first before considering a larger pool;
• The total connection count is unchanged but available connections gradually decline: check for connection leaks first; enlarging the pool will not fix the root cause.

Use the 'capacity triangle method' to estimate an initial pool size

The capacity triangle method looks at three key values together: application-layer concurrent request volume, average connection hold time per request, and the safe connection level the database can bear. The first two decide the initial pool size; the third decides the final boundary.

1. Record Q, the number of concurrent requests the application handles at peak time. By experience, take the daily average peak rather than a guessed doubled reserve; in a load testing environment, the load test thread count can approximate it.
2. Measure T, the average connection hold time per request. The typical range is tens to hundreds of milliseconds. If T exceeds one second, split the SQL or shorten the transaction before talking about enlarging the pool.
3. Estimate the theoretical connection count with C ≈ Q × T, then apply a headroom factor of 1.2 to 1.5.
4. In the load testing environment, increase concurrency step by step while observing the pool's active connection count and database load.
5. After each adjustment, run stably for 15 to 30 minutes, observe the trend, and then decide whether to continue adjusting.

Many people set the connection count only by API TPS and ignore connection hold time. For example, with TPS 100 and each request holding a connection for 500 ms, the needed connection count may be 100 × 0.5 = 50; if each request holds a connection for only 20 ms, 10 connections may be enough. Connection hold time is the most easily missed lever in connection pool tuning.

At a delivery site, a warehouse system integration exposed a slow query in an interface under refactoring, and per-request connection hold time rose from 20 ms to 800 ms, making the original pool of 30 suddenly look insufficient. The constraint was that joint debugging had to be completed the same day, so there was no time for large code changes. Comparing with the typical experience range, when hold time jumps from tens to hundreds of milliseconds, handle hold time first rather than enlarging the pool. Our move was to shorten the connection acquisition timeout from 1 second to 500 ms so that failures surfaced quickly and exposed the slow SQL, then optimize the query and narrow the transaction boundary. The pool stabilized below 40 connections and database CPU dropped. If we had jumped directly to 200, we would likely have spent the whole day troubleshooting lock waits.

Enlarge the connection count first, or investigate hold time first?

• Enlarge the connection count first: use this when connection acquisition times out but database CPU is not high and slow SQL is infrequent. The cost is low; after changing the configuration, verification usually takes a few hours to one day. But it only provides temporary relief, so keep headroom at 1.2-1.5.
• Investigate hold time first: use this when active connections stay saturated for a long time, database CPU is high, or there are signs of slow queries or long transactions. The cost is higher; locating and changing code usually takes 1-3 days, but it avoids lock contention becoming worse after enlargement. Complex problems take longer and require pulling slow SQL and transaction snapshots first.

You cannot solve code-level problems only by adjusting parameters. Enlarging the connection count can only be a transition; the final fix must come back to the connection hold time side.

What counts as a qualified adjustment: load testing and monitoring

If you cannot see any effect after adjusting the connection pool, the adjustment has effectively not been done. On the application side, look at connection acquisition wait time, active connection count, and pool utilization. On the database side, look at total connections, active sessions, CPU, and lock waits. The response time from a load testing tool is only an outcome; the metrics on both sides should be viewed on the same timeline.

• The average connection acquisition wait time should stay below tens of milliseconds; when it exceeds 200 ms, pay attention to the number of queued requests;
• At peak time, the active connection count should preferably not exceed 70%-80% of the pool maximum, leaving room for bursts;
• Database CPU under peak load testing should be controlled within 60%-70%; scenarios that already have many slow SQL statements are not covered by this indicator;
• After configuring the maximum connection count, also set a connection acquisition timeout. The experience range is 100 ms to 1 s, to avoid infinite queueing.

Following typical 2026 enterprise project delivery practice, run continuously through one business peak under the estimated peak load (typically 30-60 minutes). If there are no connection acquisition timeouts, pool utilization fluctuates instead of staying pinned to the ceiling, and database CPU does not continuously exceed the safe watermark, the initial value can run stably; afterward, keep fine-tuning based on real monitoring.

Applicable scenarios and boundaries where tuning does not apply

Connection pool capacity tuning mainly applies to online business services, especially systems with high connection establishment cost that need to handle many short requests concurrently. Low-frequency batch processing, scheduled scripts, and small tools that connect directly to a database do not need this tuning logic. Forcing a pool on a process that finishes in dozens of seconds only adds complexity.

Even if the pool is tuned well, if the database has large queries that hold connections for a long time, the application opens a network connection to the database on every request, or the connection quota is capped by the cloud instance specification, tuning the pool can hardly fix the root cause. In these cases, resolve the SQL, transaction boundaries, and working mechanism first instead of compensating with the connection count.

• Suitable: Web APIs, microservices, ERP/OMS online transaction systems;
• Not really needed: data migration, scheduled jobs, offline reports (can use independent connections and split work as batch processing);
• Not applicable: shared instances whose database connection quota has already reached its upper limit (choose a higher allowance or shard the databases first).

In online business, the connection pool size should obey the database's response capability. Connection pool configuration cannot replace slow SQL analysis and lock wait optimization.

FAQ

Does a full database connection pool necessarily mean the connection count was set too small?

Not necessarily. First check for slow SQL, uncommitted transactions, or connection leaks. After ruling these out, raise the connection count; otherwise, you are only postponing the problem.

Is it appropriate to raise the pool maximum above 200?

According to the experience range, it is uncommon for a single application to remain above 200 connections for a long time. If load testing confirms the need, verify database quota and CPU headroom first, and pair it with a shorter connection acquisition timeout.

Should the minimum and maximum connection counts be set to the same value?

For small systems with high connection establishment cost and stable traffic, they can be the same. For online services with obvious traffic fluctuation, the minimum should be lower than the maximum to retain elasticity.

What is an appropriate connection wait timeout in seconds?

The experience range is mostly 100 ms to 1 s. A value that is too short may mistake transient jitter for a failure; a value that is too long makes users wait indefinitely. If the business can fail fast and retry, set a shorter value.

Can connection pool tuning only rely on load testing?

Without a load testing environment, estimate using monitoring data, keep each adjustment within 20%-50% of the original value, change one parameter at a time, and observe at least one business peak before deciding the next step.

If you are experiencing a full connection pool or slower responses after enlargement, first collect the peak active request count, per-request connection hold time, and database load using the capacity triangle method, and then decide whether to tune the pool or optimize the calling chain. Without load testing conditions, raise the current value by 20%-50% and observe for one day; if timeouts remain frequent, continue adjusting. Connection pool size is only one part of system capacity; it should be used together with slow SQL analysis, connection leak monitoring, and timeout and retry strategies.