What is Connection Pool?

A connection pool is a software-managed collection of pre-established database connections that an application can borrow, use, and return without incurring the overhead of a full TCP handshake, TLS negotiation, or database authentication on every operation. Connection pooling is a standard pattern in most application servers, ORM frameworks, and database drivers (for example, HikariCP in the Java ecosystem, pgBouncer for PostgreSQL, or SQLAlchemy's pool in Python). Without a pool, each user request that touches the database would open a new socket, wait for the three-way handshake, authenticate against the database server, execute the query, tear down the socket, and repeat on the next request. That adds 10-50 milliseconds of latency per query before any SQL processing begins. A pool replaces that startup cost with a simple borrow-and-return cycle that takes microseconds.

The pool maintains a minimum and maximum number of connections (for example, minIdle=5, maxTotal=20). When an application asks for a connection, the pool hands back an idle one if available; if all are in use and the maximum has not been reached, the pool creates a new one. If the maximum is reached, the caller blocks (or receives a timeout error) until another thread returns a connection. The pool also validates connections: it may run a lightweight test query (e.g., SELECT 1) before handing one out to ensure the database has not closed the idle socket. Stale connections, common after a database restart or a firewall timeout, are evicted transparently.

At the infrastructure level, a connection pool sits directly between the application and the database server, often on the same host as the application. It is a critical performance tuning knob: too few connections causes queuing under load, too many exhausts database memory or file descriptors. Most pools support metrics such as active count, idle count, and pending requests so operators can right-size them for a given workload.