Database Connection Pool exhausted.

Hook: Interviewers love this question because it reveals whether you understand resource starvation, not just SQL errors.

Question: What does Database Connection Pool exhausted mean in Spring Boot?

Answer: It means every connection in the pool is already borrowed, so a new request must wait. If no connection is returned before connectionTimeout, the pool throws an error such as SQLTransientConnectionException or a Spring wrapper around it. In practice, this usually comes from a leaked connection, a very long transaction, or a pool that is too small for the traffic.

Interview-Ready Answer: In Spring Boot, a database connection pool is a limited set of ready-to-use database connections. If all of them are in use and my code asks for another one, the request waits until a connection is returned; if that wait exceeds the pool timeout, I get a pool-exhausted failure. My first checks are always: are connections being closed properly, are transactions too long, and is the pool size reasonable for the database and traffic?

What it really means

Detailed Explanation: In modern Spring Boot, the usual pool is HikariCP, which keeps a fixed number of open database connections ready to borrow. Pool exhausted does not always mean the database is dead; it usually means the app has run out of available connections right now. That is a form of starvation: a thread keeps waiting because a shared resource is busy.

How it works under the hood

1. A request reaches your repository layer, for example JdbcTemplate, JPA, or a custom DAO.
2. The code asks the pool for a connection. If a free one exists, it is borrowed immediately.
3. If all connections are already checked out, the requesting thread is parked and waits in a queue.
4. While the connection is held, any work inside the same transaction keeps that connection pinned. This is why putting slow remote calls inside @Transactional is dangerous.
5. When the code finishes and closes the resource, the pool gets the connection back and another waiting thread can use it.
6. If the wait lasts longer than connectionTimeout, Hikari throws a timeout error and Spring may wrap it in a data-access exception.

Why it happens

• Leak: A connection was borrowed but never closed.
• Long hold time: A transaction stayed open too long because of slow SQL, loops, or a remote API call.
• Undersized pool: The pool is too small for the real concurrency of the app.
• Database bottleneck: The DB is slow, so each connection stays busy longer.

How to think about fixes

Performance notes: Borrow and return are effectively O(1) when a connection is free; the pain is the wait, which is bounded by connectionTimeout. The pool itself uses space proportional to its size, and each extra live connection also costs memory and backend work on the database server. HikariCP commonly defaults to maximumPoolSize=10 and connectionTimeout=30000ms, with idleTimeout=600000ms and maxLifetime=1800000ms. Too large a pool can actually reduce throughput because the database still has finite CPU, memory, and worker threads.

Version note: In Spring Boot 2.x and 3.x, HikariCP is the default pool when it is on the classpath. Older setups could use a different pool depending on dependencies, so always check which pool implementation your app is really using.

Edge cases: Pool exhaustion and database outage are different. If the database is down, the app may fail while trying to create or validate new connections; if the pool is exhausted, the connections exist but are all busy. Also, a slow external call inside a transaction can make the pool look broken even when the SQL itself is fine.

Memory model: A pool is not the database; it is the waiting room in front of the database. If everyone keeps a seat forever, the next person at the door has nowhere to sit.

Real-World Example: In an ecommerce checkout service, one method wrapped payment validation and order writes in a single @Transactional block. During a flash sale, the payment provider slowed down, so each request held a connection for 4 to 5 seconds. The 10-connection pool emptied, new requests started timing out, and customers saw failed checkouts even though the database CPU looked normal.

The logs showed messages like Connection is not available, request timed out after 30000ms, Tomcat worker threads piled up, and support tickets mentioned carts that never completed. The real bug was not the database itself; it was the app holding scarce connections while waiting on something unrelated to SQL.

Follow-up & Tricky Questions:

• How do you tell leak vs legitimate load? Use pool metrics, leak detection, and thread dumps. If active connections never fall after requests finish, suspect a leak; if they spike only during bursts and recover later, it is usually normal load.
• What is a good pool size? There is no universal number. Start small, measure real throughput and DB CPU, and tune from data instead of guessing.
• How do @Transactional methods contribute? They hold one connection for the whole method, so slow loops or remote calls inside the transaction can starve the pool even if the SQL is simple.
• What metrics would you watch? Watch active, idle, and pending connection counts, request latency, DB CPU, and thread dumps. Rising pending threads with zero idle connections is the classic warning sign.
• What is the first production fix? Shorten the connection hold time first. Increasing the pool can buy time, but it should not hide bad code.
• Tricky: Does a bigger pool always help? No. Past the database's real capacity, more connections can increase memory use, lock contention, and context switching, which can reduce throughput.
• Tricky: Is pool exhaustion the same as database down? No. Exhaustion means your app has no free connection right now; a down database means the app may be unable to open or validate connections at all.
• Tricky: If the exception says timeout, is the database slow? Maybe, but not always. It can also mean another thread leaked a connection or a request held one while waiting on an external service.

Common Mistakes:

• Mistake: Blaming the database first. Correction: Check whether the app is holding connections too long or never returning them.
• Mistake: Increasing the pool blindly. Correction: Make sure the database can actually handle more concurrent sessions.
• Mistake: Doing network calls inside a transaction. Correction: Keep the transaction as short as possible and only around the SQL work.
• Mistake: Not using try-with-resources. Correction: Let the language close the connection automatically.

Memory Hook: Think of the pool as a parking lot: if every car stays parked, the next driver circles until the ticket machine times out.

Cheat Sheet:

• Pool exhausted = all connections are borrowed.
• Healthy borrowing is fast; waiting is the problem.
• Default Hikari pool size is commonly 10.
• Timeouts often happen after 30 seconds by default.
• Fix the leak or long hold time before raising the pool.
• Measure active, idle, and pending counts in production.

Practice Tasks:

• Set the pool size to 2 and reproduce exhaustion with two long requests.
• Break a DAO by not closing connections, then fix it with try-with-resources.
• Move a slow remote call out of a transaction and compare the pool metrics before and after.