How to Check Whether a Database Connection Pool Is Too Small

A database-backed application can become slow even when the database server has enough CPU, memory, and storage capacity. API requests may take longer to complete, background jobs may fall behind, and users may experience intermittent timeouts during busy periods.

One possible cause is a database connection pool that cannot provide connections quickly enough.

Connection pooling allows an application to reuse existing database connections instead of opening a new connection for every request. This reduces connection setup overhead and helps control the number of connections reaching the database. However, if the pool is too small for the application's workload, requests may spend time waiting for an available connection.

Increasing the pool size might appear to be the easiest solution, but it is not always the right one. A larger pool can increase database contention, memory consumption, and CPU usage. The goal is to determine whether requests are waiting for connections, understand why the pool is under pressure, and choose a suitable configuration.

This article explains how to identify connection pool bottlenecks, investigate their causes, and tune connection limits safely in a production application.

Understand How Database Connection Pooling Works

Opening a database connection involves work such as establishing a network connection, negotiating authentication, and initializing the database session. Repeating these operations for every application request can create unnecessary overhead.

A connection pool maintains a collection of reusable connections. When an application needs database access, it requests a connection from the pool. After completing its database operations, the application returns the connection so another request can use it.

Consider an application that receives 500 HTTP requests per second. If every request creates a new database connection, the database may face a large number of connection attempts and session initialization operations.

With connection pooling, the application can reuse a smaller set of connections to handle those requests.

However, a pool has a finite capacity. When every connection is in use, additional requests must wait until a connection becomes available, unless the pool can create another connection within its configured limits.

A simplified request lifecycle looks like this:

An HTTP request arrives at the application.
The application requests a database connection.
The pool returns an available connection or makes the request wait.
The application executes the required SQL operations.
The application finishes its database work and releases the connection.
Another request can reuse that connection.

The time spent waiting for a connection is separate from the time spent executing a SQL statement. This distinction is important when diagnosing application latency.

Identify the Symptoms of a Small Connection Pool

A pool that is too small can produce symptoms similar to database overload. However, there are several indicators that help distinguish connection pool pressure from other performance problems.

Common symptoms include:

API response times increase during periods of high traffic.
Requests spend a significant amount of time acquiring database connections.
The pool frequently reaches its configured maximum.
Application logs contain connection acquisition timeouts.
Database CPU usage remains moderate while application latency increases.
Increasing traffic causes request queues to grow even when individual SQL queries are reasonably fast.

None of these symptoms proves that the pool is too small by itself.

For example, a pool may reach its maximum because a few requests hold connections for too long. In that case, increasing the pool could temporarily reduce waiting, but the underlying problem would remain.

Likewise, slow SQL queries can keep connections occupied for longer than expected. The pool then becomes exhausted because connections are not being released quickly enough.

The first step is to measure connection acquisition time, connection usage, and the duration of database operations.

Monitor Connection Pool Metrics

Most database drivers and application frameworks expose some form of connection pool statistics. The exact metric names depend on the provider and library.

For example, a pool may expose the following measurements:

Metric	What it tells you	Why it matters
Active connections	Connections currently checked out by the application	Shows how much of the pool is in use
Idle connections	Connections available for reuse	Helps identify spare capacity
Maximum pool size	The configured connection limit	Defines the pool's capacity
Connection acquisition time	How long requests wait to obtain a connection	Directly reveals connection waiting
Acquisition timeouts	Requests that could not obtain a connection in time	Indicates pool pressure or another connection problem
Connection hold duration	How long a connection remains checked out	Helps identify long-running database work
Connection creation rate	How frequently new connections are opened	Can reveal churn or frequent pool expansion

Measure Connection Acquisition Time

Connection acquisition time is one of the most useful metrics for identifying a pool bottleneck.

Suppose an application reports the following measurements:

Measurement	Normal traffic	Peak traffic
Average API response time	120 ms	900 ms
Average connection acquisition time	3 ms	450 ms
Average SQL execution time	45 ms	55 ms
Pool utilization	35%	100%

In this hypothetical example, connection acquisition time increases significantly during peak traffic, while average SQL execution time changes only slightly.

That pattern suggests that requests are waiting for available connections rather than spending most of their additional time executing SQL.

These figures are illustrative, not recommended performance targets. Real thresholds depend on the application, database, workload, and latency requirements.

Also examine percentile measurements such as p95 and p99 acquisition time. An average can hide a small number of requests that experience very long waits.

Check PostgreSQL Connection Activity

If the application uses PostgreSQL, database-side monitoring can help determine whether the server is receiving too many connections or whether sessions are spending excessive time executing queries.

Start by examining current sessions:

SELECT
    application_name,
    state,
    COUNT(*) AS connection_count
FROM pg_stat_activity
GROUP BY
    application_name,
    state
ORDER BY connection_count DESC;

This query groups PostgreSQL sessions by application name and state.

It can help identify which applications have the most connections and whether many sessions are active, idle, or idle in a transaction.

The results represent database sessions, not necessarily the number of connections currently checked out from an application's pool. An idle PostgreSQL session may correspond to an idle connection retained for reuse by the application.

If multiple application instances use separate pools, their connections may appear under the same application name. Consider using distinct, meaningful application_name values when identifying different services is important.

Compare Current Connections with the Server Limit

Check the current number of connections and the configured maximum:

SELECT
    COUNT(*) AS current_connections,
    current_setting('max_connections')::integer AS max_connections
FROM pg_stat_activity;

This provides a simple view of overall connection usage.

However, max_connections is a server-wide setting, and not every connection is necessarily available to every application. Some connection slots may be reserved for privileged or administrative use, depending on the configuration.

A PostgreSQL server approaching its connection limit does not automatically mean that an individual application's pool is too small. It may indicate that too many application instances or services are opening connections.

Conversely, a server with plenty of unused connection slots can still have an application whose own pool is exhausted.

These are separate problems and should be investigated separately.

Understand Why Connections Remain Occupied

A connection pool can become exhausted even when its configured size is reasonable. One of the most important investigation steps is determining how long connections remain checked out.

Long-Running SQL Queries

A slow query holds its connection until the application finishes the database operation and releases the connection.

Common causes include:

Missing or ineffective indexes.
Queries that scan or process more data than necessary.
Expensive joins and aggregations.
Lock waits caused by concurrent transactions.
Database CPU or I/O bottlenecks.

Use PostgreSQL activity information to inspect active sessions:

SELECT
    pid,
    application_name,
    state,
    wait_event_type,
    wait_event,
    query_start,
    clock_timestamp() - query_start AS query_duration,
    LEFT(query, 200) AS query_sample
FROM pg_stat_activity
WHERE state = 'active'
  AND pid <> pg_backend_pid()
ORDER BY query_start;

Long-running queries deserve investigation, but duration alone does not identify the root cause. Check wait events and execution plans to determine whether sessions are executing, waiting for a lock, or waiting for another resource.

Connections Held During Unnecessary Work

An application may acquire a connection and then perform unrelated operations before returning it to the pool.

For example, a request might execute a database query, call an external API, perform additional processing, and only then release the connection.

If the external API takes several seconds to respond, the database connection may remain occupied even though the database has finished its work.

Where possible, keep the connection checkout period limited to the operations that require database access. Avoid holding connections during unrelated network requests or lengthy application processing.

Transactions That Remain Open

An application can also hold a connection while a transaction remains open longer than necessary.

Long-running transactions may interfere with database maintenance and increase contention. Sessions that are idle in a transaction deserve particular attention because they may indicate that application code has not completed or closed a transaction correctly.

Inspect such sessions with:

SELECT
    pid,
    application_name,
    usename,
    state,
    xact_start,
    clock_timestamp() - xact_start AS transaction_duration,
    LEFT(query, 200) AS query_sample
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY xact_start NULLS LAST;

Investigate why these transactions remain open before changing the pool size.

Calculate a Reasonable Starting Pool Size

Pool sizing should be based on the application's concurrency, connection hold duration, database capacity, and latency requirements.

A useful starting point is Little's Law:

Average concurrent work in progress = arrival rate × average time in the system.

For database connection planning, a simplified estimate is:

Average connections in use ≈ database operations per second × average connection hold time in seconds.

Suppose an application performs 200 database operations per second, and each operation holds a connection for an average of 40 milliseconds.

Convert 40 milliseconds to 0.04 seconds:

200 × 0.04 = 8

The average number of connections in use would be approximately eight under those assumptions.

This does not mean that a pool of eight connections is necessarily sufficient. Peak traffic, variable query duration, transactions involving multiple operations, and latency targets all affect the required capacity.

It is also important to define what counts as an operation. A single HTTP request might execute several database operations sequentially or hold one connection throughout a transaction.

Use measured connection hold durations and peak workload data to estimate capacity. Then validate the proposed pool size through load testing.

Configure the Connection Pool Carefully

Connection pool settings differ across database providers. In a .NET application using Npgsql, for example, connection pooling is enabled by default.

A connection string can specify a maximum pool size:

var connectionString =
    "Host=localhost;" +
    "Database=appdb;" +
    "Username=appuser;" +
    "Password=your-password;" +
    "Maximum Pool Size=50;" +
    "Timeout=15;";

This example sets a maximum pool size of 50 and a connection timeout of 15 seconds. These are illustrative settings, not universal recommendations.

The timeout setting should be checked against the documentation for the exact driver version and its meaning. In this example, the Npgsql connection timeout controls how long opening a connection may take, including obtaining one from the pool.

Do not increase Maximum Pool Size simply because requests are waiting. First verify whether the database has sufficient capacity to handle additional concurrent work.

Account for Multiple Application Instances

One common configuration mistake is considering the pool size of a single application instance without accounting for the entire deployment.

Suppose a service runs eight instances, and each instance has a maximum pool size of 50.

The application tier could potentially open:

8 × 50 = 400 connections

That estimate excludes connections from background workers, administrative tools, migrations, monitoring systems, and other services.

If the application scales to more instances during peak traffic, the total potential connection count may increase further.

For this reason, connection pool sizing must consider the whole deployment rather than an individual process.

Compare the Available Solutions

Increasing the pool size is only one possible response to connection waiting.

Approach	When it helps	Potential drawback
Increase the pool size	The database has spare capacity and requests are waiting for connections	May increase database contention and resource usage
Optimize slow SQL queries	Connections remain occupied because queries take too long	Requires query investigation and testing
Shorten connection hold duration	Connections remain checked out during unrelated work	May require changes to application flow
Reduce unnecessary database calls	The application repeatedly performs avoidable operations	Requires changes to data-access patterns
Add a connection pooler	Many clients create more server connections than necessary	Introduces configuration and operational considerations
Limit application concurrency	Too many simultaneous operations overwhelm the database	Can increase application-side queueing if configured poorly

A connection pooler such as PgBouncer may help in suitable PostgreSQL deployments, particularly when an application creates many client connections. However, pooling modes have different transaction and session semantics, so compatibility must be checked before deployment.

Test Pool Changes Before Production

Once you identify a likely pool bottleneck, validate the proposed change under a representative workload.

Use a staging environment with realistic query patterns and concurrency. Compare the current configuration with the proposed configuration while monitoring application and database metrics.

Track:

Connection acquisition latency, including p95 and p99.
Pool utilization and acquisition timeouts.
Database CPU and memory usage.
Query execution time and throughput.
PostgreSQL connection count.
Application response latency and error rates.

If increasing the pool size reduces acquisition latency but causes database CPU usage to rise sharply, the larger pool may be allowing more concurrent work than the database can handle efficiently.

If reducing query duration improves acquisition latency without increasing the connection limit, query optimization may be the more effective solution.

Change one major setting at a time where practical, and keep a clear record of the results.

Common Mistakes to Avoid

Increasing the Pool Size Without Measuring Database Capacity

A larger pool can reduce application-side waiting while increasing pressure on the database. Check CPU, memory, query performance, and total connection usage before raising the limit.

Confusing Idle Connections with Wasted Connections

Idle connections retained by a pool are often normal. Their purpose is to be reused. Investigate whether the pool is exhausted and whether acquisition waits are occurring instead of treating every idle connection as a problem.

Looking Only at Average Latency

Average acquisition time may look acceptable while a subset of requests experiences severe delays. Review latency percentiles and timeout counts.

Ignoring Connection Leaks

If application code fails to dispose of connections correctly, the pool can become exhausted even at modest traffic levels. In .NET, use appropriate disposal patterns, such as using statements or asynchronous disposal where supported.

Treating the Database Connection Limit as the Pool Size

The PostgreSQL server connection limit and an application's pool limit control different things. A service can exhaust its own pool while the database has spare capacity, or the entire database can approach its connection limit even when individual pools appear healthy.

Advantages and Limitations of Connection Pool Monitoring

Connection pool monitoring helps developers identify where requests spend time, distinguish connection waiting from query execution, and make better decisions about concurrency and pool configuration.

It also helps teams detect connection leaks, unexpectedly long transactions, and resource pressure during traffic spikes.

However, pool statistics alone cannot establish the complete cause of a bottleneck. Driver metrics vary, connection usage can change rapidly, and database-side sessions do not always map directly to application pool states.

For an accurate diagnosis, combine pool telemetry with PostgreSQL activity, query performance, database resource metrics, and application traces.

Summary

A database connection pool may be too small when requests regularly wait for available connections, but pool exhaustion is often a symptom rather than the underlying problem.

Start by measuring connection acquisition latency, active and idle connections, pool utilization, and timeout frequency. Compare those measurements with PostgreSQL session activity, query execution times, and database resource usage.

If connections remain occupied because of slow SQL, long transactions, or unrelated application work, address those problems before increasing the pool size. If the database has sufficient capacity and measured demand exceeds the current pool's capacity, a carefully tested increase may be appropriate.

The objective is to balance application concurrency with database capacity. A well-sized connection pool reduces unnecessary waiting without overwhelming the database or hiding problems in the application's data-access patterns.