With virtual threads enabled by default in Spring Boot 4.1, a system may receive many more requests waiting on database access at the same time. But if the connection pool remains small, interface timeouts may increase instead. What we really care about is not “how many times has concurrency increased,” but whether the bottleneck has shifted from request threads to database connections.
What This Is
Virtual threads are a lightweight concurrency mechanism introduced in Java 21. While waiting for I/O, they no longer occupy an operating system thread for long periods, making them well suited to situations where large numbers of requests query databases or call external services simultaneously. HikariCP, a widely used database connection pool, limits the number of concurrent connections between an application and its database.
Spring Boot 4.1 enables virtual threads by default when runtime conditions are met, but HikariCP’s default pool size is still designed around the traditional threading model. The result may be thousands of requests queuing simultaneously for roughly 10 database connections, eventually triggering timeouts. A larger pool is not always better: the total number of connections used across all services should remain within the database’s capacity. Slow SQL and missing indexes can also keep connections occupied for extended periods.
Common adjustments include moderately increasing the pool size, shortening connection wait times, and enabling lazy connection acquisition so requests served from caches do not reserve connections before they actually need database access. Java 21 also introduced a pinning issue: when a thread blocks inside a synchronized lock, it cannot release its carrier thread. Upgrading to a newer JDK or switching to a suitable locking mechanism can reduce this risk.
Industry View
This shows that upgrades to enterprise software, even outside AI applications, cannot be evaluated solely through framework defaults. Virtual threads solve the problem of “how many requests the system can accept,” but they do not solve the question of “how many database connections the database can handle.” Treating interface concurrency as equivalent to business throughput can concentrate pressure on the database layer, where costs are higher and horizontal scaling is more difficult.
The risk is equally clear: if teams expand the connection pool without load testing, database CPU usage, lock contention, and session counts may reach their limits first, bringing down the entire system. A larger connection pool therefore cannot replace SQL optimization and capacity governance. Nor is there a reason to layer virtual threads onto WebFlux projects that already use reactive programming.
Impact on Regular People
For enterprise IT: After upgrading the framework, teams should review database connection pools, slow queries, and lock contention together, then use steady-state load tests to verify wait counts and timeout counts rather than merely checking whether CI passes.
For individual careers: Technologists’ value is shifting from “completing the code” toward identifying system bottlenecks, verifying the effects of configuration changes, and explaining their business impact. This increases the weight of troubleshooting and architectural judgment.
For the consumer market: For most end users, virtual threads provide no visible feature of their own. Their likely impact is faster and more stable performance in high-concurrency services such as e-commerce and financial services, provided that backend resources scale in tandem.