HikariCP Connection Pool Tuning for Spring Boot: The Complete Guide (2026)

HikariCP is the default connection pool in Spring Boot, and it's fast by design. But the default configuration is sized for development, not production. A misconfigured pool causes connection timeouts, thread starvation, and cascading failures under load - even when your database is perfectly healthy.

---

Why Connection Pool Sizing Matters

Every request that touches the database needs a connection from the pool. If all connections are in use, incoming requests queue up waiting. If the queue fills, requests fail with:

com.zaxxer.hikari.pool.HikariPool$PoolInitializationException
java.sql.SQLTransientConnectionException:
  HikariPool-1 - Connection is not available, request timed out after 30000ms

The default maximum-pool-size in HikariCP is 10. For a service handling hundreds of concurrent requests, this will cause problems.

---

The Right Formula for Pool Size

The HikariCP team references a well-known formula: you don't need as many connections as you think.

pool_size = (core_count * 2) + effective_spindle_count

# 4-core server with SSD (spindle_count = 1):
pool_size = (4 * 2) + 1 = 9 ? 10

# 16-core server hitting PostgreSQL:
pool_size = (16 * 2) + 1 = 33

More connections don't mean more throughput - they increase context switching and lock contention on the database. A smaller pool that keeps the DB busy is faster than a large pool that queues at the DB level.

---

Essential HikariCP Configuration

# application.properties - production-ready HikariCP config

# Pool sizing
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.minimum-idle=5

# Connection acquisition - fail fast instead of hanging 30s
spring.datasource.hikari.connection-timeout=3000

# Keep-alive (prevents stale connections)
spring.datasource.hikari.keepalive-time=30000
spring.datasource.hikari.max-lifetime=1800000
spring.datasource.hikari.idle-timeout=600000

# Pool name - visible in logs and metrics
spring.datasource.hikari.pool-name=MyAppPool

What Each Setting Does

• connection-timeout (3000ms) - How long a request waits for a connection. Default is 30s - too long for web requests. Set to 3s to fail fast.
• max-lifetime (1800000ms = 30min) - Maximum lifetime of a connection. Must be less than your database's wait_timeout (MySQL default: 8h). Critical for cloud databases that drop idle connections.
• keepalive-time (30000ms) - HikariCP sends a keepalive query on idle connections to prevent them from being dropped by firewalls or cloud load balancers.
• minimum-idle - Set equal to maximum-pool-size for a fixed pool (HikariCP's recommendation for best performance).

---

Monitoring the Pool with Spring Boot Actuator

Add these dependencies to expose HikariCP metrics via Micrometer:

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

management.endpoints.web.exposure.include=health,metrics,prometheus
management.metrics.enable.hikaricp=true

Key metrics to watch at /actuator/metrics:

---

Multi-Datasource Configuration

If your app has multiple data sources (primary + read replica), configure separate pools:

@Configuration
public class DataSourceConfig {

    @Bean
    @ConfigurationProperties("spring.datasource.primary.hikari")
    public HikariDataSource primaryDataSource() {
        return new HikariDataSource();
    }

    @Bean
    @ConfigurationProperties("spring.datasource.replica.hikari")
    public HikariDataSource replicaDataSource() {
        return new HikariDataSource();
    }
}

---

Common Mistakes to Avoid

• Leaving default pool size (10) in production - the default works for dev; a real service needs sizing based on core count and DB capacity
• Setting connection-timeout to 30s (default) - users see a 30-second hang before a failure; set it to 2-5s to fail fast
• Not setting max-lifetime - cloud databases (RDS, Cloud SQL) silently drop idle connections; without max-lifetime, you get stale connection errors at random
• Pool size larger than DB's max_connections / (number of app instances) - if PostgreSQL has max_connections=100 and you run 5 instances each with pool size 50, you'll get connection refused from the DB itself

---

Summary

HikariCP is fast out of the box, but production requires deliberate tuning. Size the pool based on the CPU-core formula, set a short connection-timeout to fail fast, configure max-lifetime to survive cloud database connection resets, and add Actuator metrics to catch pool exhaustion before users do.

---

Find Database Performance Issues Across Your Codebase

JOptimize scans your Spring Boot project for patterns that stress the connection pool - unbounded queries, missing pagination, missing transaction boundaries - and prioritizes them by impact.

• IntelliJ Plugin - flags connection-pool anti-patterns inline with AI-generated fixes: Install JOptimize for IntelliJ
• Web Dashboard - scan your entire repo and get a prioritized fix list: Analyze your project free ?

Spot database bottlenecks before your pool exhausts - free scan, no configuration required.