What is HikariCP?

Hook: Interviewers love this question because it tests the invisible part of production performance: the thing that quietly makes every database call fast or slow.

Question: What is HikariCP?

Answer: HikariCP is a fast JDBC connection pool used by Spring Boot to reuse database connections instead of creating a new one for every query. JDBC means Java Database Connectivity, the standard Java API for talking to relational databases. HikariCP keeps a small set of ready-to-use connections, which lowers latency and protects the database from too many open sessions.

Interview-Ready Answer: I’d say HikariCP is the connection pool I expect to see behind most Spring Boot database work. It manages reusable JDBC connections so my code can borrow one, use it, and return it quickly instead of opening a brand-new database session each time. That cuts overhead, improves throughput, and helps avoid database overload. A nice production detail is that HikariCP is lightweight and very fast, which is why Spring Boot commonly picks it automatically when it is on the classpath.

Detailed Explanation: HikariCP is a JDBC connection pool. A connection pool is a managed cache of open database connections. Opening a real DB connection is expensive because it may involve TCP setup, authentication, SSL, and session creation. HikariCP keeps a small, warm set of connections ready so your app can borrow one in milliseconds instead of paying that setup cost for every query.

How it works under the hood

1. Spring Boot creates a HikariDataSource when HikariCP is on the classpath and no other pool is chosen. A DataSource is the JDBC interface that hands out connections.
2. Your code calls getConnection() through JDBC, Spring JDBC, or Hibernate-style persistence code.
3. Hikari first tries to hand out an idle connection. If none are idle, it creates a new one until maximumPoolSize is reached.
4. The connection you receive is a lightweight proxy. A proxy is a wrapper object that looks like a connection but lets Hikari track usage and return it safely to the pool.
5. When you call close(), the physical DB session is usually not closed; it is returned to the pool for reuse.
6. A housekeeping thread checks idle connections, retires old ones at maxLifetime, and can log a warning if a connection is borrowed too long. That warning is leak detection, meaning the pool suspects you forgot to close a connection.
7. If all connections are busy, the caller waits up to connectionTimeout (default 30000 ms). If nothing becomes free, Hikari throws an exception instead of hanging forever.

When and why to use it

Use HikariCP whenever your Spring Boot app talks to a relational database through JDBC. It is the normal production choice because it is fast, small, and predictable. It protects the database by limiting concurrent sessions and it reduces latency by reusing connections. In other words: fewer expensive opens, more cheap reuses.

What to tune first

• maximumPoolSize: usually the first setting to inspect; common starting values are 10 to 30, not hundreds.
• connectionTimeout: how long callers wait for a free connection; default 30 seconds.
• idleTimeout: default 10 minutes.
• maxLifetime: default 30 minutes; set it a little shorter than the database server’s own timeout.

A useful mental model is this: the pool is a parking garage, not an infinite highway. If you add too many cars, the garage becomes crowded and slower to move through. A bigger pool is not always faster because the database still has to do the real work, and extra connections can increase contention instead of reducing it.

Comparison with other pools

From a complexity point of view, the common borrow and return path is effectively O(1), and the space cost is roughly one live DB session per pooled connection. That is why pool size matters: each extra connection consumes memory and database resources. If the app holds connections during long transactions or slow network calls, throughput drops quickly, even if CPU looks idle.

One gotcha is that closing a pooled connection does not mean “kill the DB session.” It means “return it for reuse.” Another gotcha is stale connections: if your database closes sessions after 15 minutes, but Hikari keeps them for 30 minutes, you can see broken connections unless maxLifetime is tuned below the server timeout.

Real-World Story: Imagine a checkout service during a flash sale. Each request needs a few DB calls: reserve inventory, write the order, record payment state. The team leaves HikariCP at a tiny pool size from development, or one code path forgets to close a connection. Under load, requests pile up, threads wait for a connection, and users see spinning checkouts. Logs show Connection is not available, request timed out after 30000ms, while the database is not even maxed out. The root cause is usually a leak or an undersized pool: a connection was borrowed and never returned, or a long transaction held it too long. Hikari makes the problem visible quickly, but it cannot fix broken usage by itself.

Follow-up & Tricky Questions:

• Why is HikariCP preferred over other pools? It is lightweight, fast, and has a very small overhead on the common borrow/return path. In Spring Boot it is the default-style choice for most relational database workloads.
• Which Hikari settings do you tune first in production? Start with maximumPoolSize, then check connectionTimeout and maxLifetime. Pool size should match real database capacity, not guesswork.
• What does a connection leak mean? A leak means the application borrowed a connection and never returned it with close(). Hikari can warn about this with leak detection, which usually points straight to the bad code path.
• How do you know the pool is the bottleneck? Look for waiting threads, low CPU, and logs such as Connection is not available. If the database is healthy but callers are blocked, the pool size or connection lifetime is often the first thing to inspect.
• How do you choose pool size? Start small, measure, and increase only if the database can still handle the extra concurrency. The best size depends on query time, database CPU, and how many requests actually need the database at the same moment.
• Does a bigger pool always improve throughput? No. Past a point, more connections create more contention, more memory use, and more load on the database. The fastest pool is the smallest one that keeps the database busy without overwhelming it.
• Does close() really close the database connection? In a pool, close() normally returns the connection to HikariCP instead of physically dropping the DB session. That is the whole benefit of pooling: reuse without paying the full reconnect cost.
• Is HikariCP the same as Hibernate or JPA? No. HikariCP sits underneath them as the connection pool, while Hibernate/JPA are ORM tools that map objects to tables. They solve different problems and often work together.

Common Mistakes:

• Thinking HikariCP is a database. Correction: it is a pool that manages connections to a database.
• Confusing close() with a real disconnect. Correction: in a pool, close() usually returns the connection to reuse.
• Setting the pool size very high “just in case.” Correction: oversized pools often slow systems down and stress the database.
• Ignoring timeouts and leak warnings. Correction: these are early signals of bugs, slow queries, or bad transaction boundaries.

Memory Hook: Think of HikariCP as a valet parking garage for database connections: you hand over the keys, get a car quickly when you need it, and return it when you are done. You are not buying new cars every trip; you are reusing the same fleet.

Cheat Sheet:

• HikariCP is a fast JDBC connection pool.
• Spring Boot commonly uses it by default when available.
• Borrowing and returning connections is cheap; opening them is expensive.
• Watch maximumPoolSize, connectionTimeout, idleTimeout, and maxLifetime.
• Always close connections; otherwise you leak pool slots.
• Big pools are not automatically faster.

Practice Tasks:

• Run a Spring Boot app with H2 and print Hikari pool stats from a controller.
• Lower maximumPoolSize to 1 or 2 and observe how requests start waiting or timing out.
• Introduce an intentional connection leak in a test method, then watch the pool behavior and fix it by closing the connection properly.