HikariCP: A Fast, Zero-Overhead JDBC Connection Pool for Java

What HikariCP solves and who it is for

Every Java application that talks to a relational database over JDBC pays a cost to acquire and release connections. Without pooling, each database operation opens a TCP connection, authenticates, runs the query, and closes the connection. HikariCP maintains a pool of pre-opened, authenticated connections that are checked out and returned rather than created and destroyed on each request.

The README describes it as "zero-overhead", attributing this to careful attention to bytecode-level optimization, the use of a custom lock-free concurrent queue, and aggressive avoidance of JVM overhead. The library weighs roughly 165 KB, which is small enough to include in any deployment without size concerns. The primary audience is Java backend developers who need reliable, low-latency database connection management in production.

How connection acquisition and pool sizing work

HikariCP defines two core cycle types in its benchmark model. A Connection Cycle is one DataSource.getConnection() and Connection.close() pair. A Statement Cycle is one Connection.prepareStatement(), Statement.execute(), and Statement.close() sequence. Both measurements isolate pool overhead from query execution time.

A counterintuitive aspect documented in the README is pool sizing. The project links to its "About Pool Sizing" wiki page and to an Oracle Real-world Performance Group presentation, both of which argue that more connections do not mean better performance. The README notes that in the Oracle demonstration, too many connections caused a 50x performance difference versus an appropriately sized pool. HikariCP's configuration therefore encourages smaller pools rather than large ones.

The pool shrinks and grows dynamically. The README documents a spike demand analysis showing how HikariCP handles a scenario with high connection acquisition cost and unpredictable request bursts, comparing behavior against other pools.

Adding HikariCP to a Java project

The README provides Maven dependency declarations for each supported Java version. For Java 11 and later, the current release is version 7.1.0:

<dependency>
   <groupId>com.zaxxer</groupId>
   <artifactId>HikariCP</artifactId>
   <version>7.1.0</version>
</dependency>

For Java 8, the README marks the 4.0.3 artifact as deprecated. Java 7 and Java 6 artifacts exist at even older versions, also marked deprecated. The clear message is that Java 11 or newer is the supported path.

Beyond the Maven artifact, the README points to the Javadocs for the configuration API. The configuration section covers essential properties (connection URL, username, password, pool name), frequently used properties (maximum pool size, connection timeout, idle timeout), and infrequently used options. There is no separate configuration file format; properties are set programmatically or via standard DataSource properties.

TCP keepalive: a required configuration step

The README contains an important warning about a pool recovery failure mode. Under rare conditions, the pool can drop to zero active connections and fail to recover because idle connections are silently dropped by the network between the application and the database. The fix is TCP keepalive.

The README documents two paths. For PostgreSQL specifically, the JDBC driver supports a tcpKeepAlive=true property. For any database, the same effect can be achieved at the OS level. The README links to its own wiki page on setting OS-level TCP keepalive and to an external Cybertec article on the subject.

This is a production-readiness detail that is easy to miss. Environments where the database is on a different host, behind a load balancer, or separated by a firewall with connection-tracking timeouts are the most likely to encounter this failure. The fix is one driver property or a set of OS-level sysctl values, but the README makes clear it should be considered mandatory rather than optional.

Limitations and when HikariCP is the wrong choice

HikariCP pools JDBC connections. It does not work with reactive data access libraries that use non-blocking IO (such as R2DBC). For projects on Spring WebFlux or other reactive stacks that avoid thread-per-request blocking, a reactive connection pool designed for R2DBC is the appropriate tool.

HikariCP also does not manage connection routing, which matters for applications that need to direct reads to replicas and writes to a primary. That logic lives in the application or a middleware layer, not in the pool.

The README notes that the repository has no GitHub releases in the standard metadata, but artifacts are published to Maven Central under com.zaxxer:HikariCP. The last push to the repository was on 2026-06-14, which is within six months of the article date, so the project is active.

A less obvious constraint is that HikariCP validates pool configuration eagerly on startup. A misconfigured maxPoolSize or connectionTimeout will cause the application to fail at launch rather than at query time. This is a feature for production but can be surprising in test environments where a database is not available at startup.

HikariCP versus PgBouncer and C3P0

C3P0 is an older Java JDBC pool that predates HikariCP by over a decade. The README includes JMH benchmark data showing that in both uncontended (32 threads, 32 connections) and contended (32 threads, 16 connections) scenarios, Apache DBCP and Tomcat's pool fail to complete the Statement benchmark due to excessive garbage collection. HikariCP's design avoids the allocations that cause those GC pauses.

PgBouncer is a different category of tool. It is a process-level connection pooler that sits between application servers and a PostgreSQL database, maintaining a smaller number of actual database connections shared across many application pools. HikariCP runs inside the JVM and pools JDBC driver connections from a single application process. The two are not mutually exclusive: many deployments run HikariCP inside the application and PgBouncer in front of the database, with each serving a different layer of the connection cost.

For Spring Boot specifically, HikariCP is the default pool since Spring Boot 2.0, meaning it requires no extra configuration to activate when added to a Spring project.

Editorial conclusion

HikariCP is the sensible default JDBC connection pool for any Java 11 or newer application, and its position as Spring Boot's default pool means most teams are already using it without configuration. Teams that need to tune it should start with the About Pool Sizing wiki page before increasing pool sizes, since the README documents that too many connections actively hurt performance. For PostgreSQL deployments specifically, configure TCP keepalive via the tcpKeepAlive=true driver property or at the OS level to avoid pool recovery failures after network interruptions.

Frequently asked questions

Official sources

1. brettwooldridge/HikariCP on GitHub
2. Issues
3. License: Apache-2.0
4. README