Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Spring Boot JDBC pool capacity: size connections across replicas

Last updated: 1 Oct 20265 min read
tutorial
IntermediateBy AITrove Editorial

A JDBC connection pool caps how many database connections one application instance can use at once. Spring Boot commonly selects HikariCP when the JDBC starter provides it; the pool is a resource limit, not a promise that every HTTP request receives a connection immediately.

Multiply the limit before deployment

Six replicas with a maximum of 12 connections can request 72 database connections. Leave capacity for migrations, admin work and other services. More connections can increase lock contention and database memory use while barely changing throughput. Start from measured query time, concurrency and the database budget.

properties
spring.datasource.hikari.maximum-pool-size=12
spring.datasource.hikari.connection-timeout=750
Java
package in.aitrove.receipts;

public class ConnectionBudget {
    public static void main(String[] args) {
        int applicationReplicas = 6;
        int connectionsPerReplica = 12;
        int migrationReserve = 8;
        int databaseLimit = 100;
        int possibleConnections = applicationReplicas * connectionsPerReplica
            + migrationReserve;
        System.out.println(possibleConnections <= databaseLimit);
        System.out.println(possibleConnections);
    }
}

The calculation prints true and 80. It is a ceiling estimate, not a throughput forecast. Connection acquisition timeout bounds how long a request waits when the local pool is exhausted; it does not cancel a slow SQL statement or an external API call. Keep remote calls out of open transactions when the business contract allows it.

Watch wait time, not just utilization

Measure active, idle and pending connections together with database query latency. A rising pending queue can be caused by slow queries, leaked connections, long transactions or too much concurrent work. Increasing the pool before finding which one is happening can move the outage to the database.

Common Mistakes

  • Sizing one instance without multiplying by peak replica count.
  • Holding a connection while waiting on a remote service.
  • Interpreting an acquisition timeout as proof that the database is down.
  • Using an embedded database benchmark as a production sizing test.

Read next

TransactionTemplate, transaction propagation, and health signals.

spring
spring-boot
jdbc-pool-capacity
Storage details