A database connection pool is often configured inside one application process. The operational consequences extend beyond that process.
When a startup scales from two application replicas to six, it also multiplies the number of connections those replicas may open. Background workers, administration tools, and overlapping deployments add further demand.
A useful connection budget begins with the whole system rather than a single configuration file.
Count the potential connections
Consider a hypothetical application with six replicas, each configured for a maximum of 12 direct database connections. Together, those pools could account for 72 connections.
Add two worker processes with a maximum of eight each, and the potential total becomes 88 before including other services.
These figures are an illustrative planning example, not recommended defaults. The appropriate limits depend on the application, database, and workload.
If a connection proxy or external pooler sits between the application and database, model that layer separately. Front-end client connections and back-end database connections may not have a one-to-one relationship.
Know what the pool limit means
HikariCP documents maximumPoolSize as the maximum number of connections in the pool, including idle and in-use connections. When no idle connection is available and the limit has been reached, a request can wait until the configured connection timeout.
This means a timeout can reflect waiting for a pooled connection. It does not, by itself, identify the reason that connections remain occupied.
Investigate the work holding them. A slow query, a long transaction, or an application path that retains a connection unnecessarily can create pressure even when the configured maximum looks generous.
Increasing the limit without understanding the cause may simply move the bottleneck.
Leave room for the database’s other users
PostgreSQL’s max_connections setting controls the number of concurrent connections the server can accept. Its configuration also supports reserved connection slots for defined access conditions.
An application budget should account for more than the busiest web service. Include workers, scheduled jobs, monitoring, migrations, and operational access.
For a fictional database budget of 100 connections, the earlier 88-connection example leaves only 12 for everything else. Whether that is sufficient requires actual operational knowledge.
Do not treat the entire server limit as an entitlement for one application.
Include deployment overlap
Steady-state replica counts can underestimate peak demand. A rolling deployment may temporarily run old and new instances together.
Calculate a plausible overlap scenario using the deployment strategy actually configured. Repeat that exercise for autoscaling limits and scheduled workloads.
This simple review often exposes a hidden dependency: a deployment that is safe at low traffic may become risky when additional replicas are already running.
Keep the calculation alongside the relevant configuration so that future changes are reviewed together.
Measure before tuning
Observe active connections, idle connections, time spent waiting for the pool, and database work duration during a representative load test.
Then change one limit at a time and compare the result. A successful adjustment should improve the intended service behavior without exhausting capacity elsewhere.
Connection pools are a shared-capacity decision. Startups gain a more reliable scaling plan when replica counts, pool sizes, deployment overlap, and database limits are treated as parts of one budget.
Sources: