Connection Pooling
Last Updated: June 12, 2026
Practice this topic in a realistic system design interview
Database connections are expensive resources.
Opening a connection can involve a TCP handshake, TLS negotiation, authentication, session setup, and database process or thread allocation. Keeping a connection open also consumes memory, file descriptors, backend state, and scheduling overhead on the database.
If an application opens a new database connection for every request, it wastes time and can overload the database long before the actual queries become expensive.
Connection pooling solves this by keeping a limited set of open connections and reusing them across requests.
The size limit on the pool is what makes it more than a performance optimization. It also acts as a safety mechanism that controls how much concurrent work the application can send to the database.
1. The Problem Without Pooling
Without pooling, a request may do this every time it needs the database:
- Open a TCP connection.
- Negotiate TLS if enabled.
- Authenticate with the database.
- Allocate database-side session state.
- Run the query.
- Close the connection.
For one request, this may be acceptable. Under load, it becomes painful.
Problems include:
- Higher latency: connection setup may take longer than a small indexed query.
- Database overhead: each connection consumes memory and scheduling resources.
- Connection storms: traffic spikes can create a burst of new connections at the worst time.
- Resource leaks: missed cleanup can leave connections idle but unusable.
- Connection limits: databases reject new clients when limits are reached.
The database wants a manageable amount of concurrent work. Creating thousands of connections does not make it process thousands of queries efficiently. It often creates contention and queueing inside the database.