connection pool
/kuh-NEK-shun pool/ · noun · Development · Origin: 1997
Definitions
A cache of reusable database connections maintained by an application or middleware (like PgBouncer) to avoid the overhead of establishing a new connection for each request. Creating a database connection involves TCP handshake, TLS negotiation, and authentication — too expensive to do per-request. Pool exhaustion under load is a common cause of application outages.
In plain English: A set of pre-opened database connections that get reused instead of creating new ones each time — like having a pool of rental cars ready instead of buying a new car for every trip.
Example: The app crashed under load because it was opening a new connection per request. Adding PgBouncer with a connection pool of 20 fixed it immediately.
Etymology
- 1990s
- Early web applications opened a new database connection for every HTTP request. As traffic grew, the overhead of TCP handshakes and authentication became a severe bottleneck.
- 1997
- Java's JDBC 2.0 specification introduced standardized connection pooling. Libraries like PoolMan emerged, recycling database connections across requests.
- 2000s
- Connection pooling became a default feature in application servers (Tomcat DBCP, C3P0) and web frameworks. It extended beyond databases to HTTP clients and thread pools.
- 2010s-Present
- Modern poolers like PgBouncer and HikariCP pushed efficiency further. Connection pooling became critical in serverless environments where cold starts made per-request connections impractical.
Origin Story
Sharing Connections So Databases Don't Drown
A connection pool is a cache of reusable database connections maintained by an application or middleware, eliminating the overhead of repeatedly opening and closing connections for each request. The pattern became essential in the late 1990s with the rise of Java Enterprise Edition (J2EE) and high-traffic web applications. Creating a new database connection is expensive: it involves TCP handshakes, authentication, memory allocation on the server, and sometimes SSL negotiation, all of which can take tens of milliseconds. For a web application handling hundreds of requests per second, this overhead becomes a bottleneck. Connection pooling solves the problem by maintaining a set of pre-established connections that threads can borrow and return. Sun Microsystems formalized the pattern in the JDBC 2.0 specification (1998), and application servers like WebLogic and WebSphere made it a standard feature. In the open-source world, libraries like Apache DBCP, C3P0, and later HikariCP (which became the default in Spring Boot) refined the approach. The pattern extended beyond databases to any expensive resource: thread pools, HTTP connection pools, and object pools all follow the same principle of reuse over recreation.
Context: Formalized in the JDBC 2.0 specification (1998) and popularized by J2EE application servers.
Fun fact: HikariCP, the most popular Java connection pool, takes its name from the Japanese word for 'light.' Its author, Brett Wooldridge, optimized it so aggressively that benchmark comparisons show it handling connections in nanoseconds, orders of magnitude faster than older pools.