Connection Pooling
The problem
Opening a new database connection for every single query is expensive — a fresh socket, a TCP handshake, and often authentication, all repeated per query — and a database can only sustain a limited number of simultaneous connections before its own performance degrades.
Why now
Sockets and ports already established that opening a connection has real setup cost; connection pooling is the direct fix — reuse a small set of already-open connections instead of paying that cost repeatedly — and it needs the concurrency-safety discipline from concurrency and synchronization because a pool is shared, contended state.
Mental model
A connection pool is a small, pre-opened stock of database connections shared across many requests: borrow one when you need to query, return it when you're done, and let the pool block or queue new requests if all connections are currently checked out — the same 'shared, contended resource' pattern already covered, just applied to sockets instead of a lock.
Requires
- Sockets & PortsNetworking
A database connection is a socket, and the setup cost pooling avoids (handshake, authentication) is exactly the socket-establishment cost already covered — you need that cost to be real to you before pooling's benefit registers.
- Concurrency & SynchronizationOperating Systems
A connection pool is shared state accessed by many concurrent requests simultaneously; checking out and returning a connection safely requires the same synchronization discipline already covered for any shared resource.
Used in
- Every production backend talking to a relational database at meaningful request volume
- PgBouncer and similar dedicated connection-pooling proxies
- Diagnosing 'too many connections' errors under load as a pool-sizing problem
- Serverless architectures, where connection pooling requires special handling due to short-lived function instances
Projects
- Benchmark opening a new database connection per query versus reusing a pooled connection, across 1,000 sequential queries
- Configure a connection pool's size for a simulated workload and observe request queueing behavior once the pool is exhausted
Examples
- A web server handling 1,000 requests per second with a pool of 20 connections reuses each connection roughly 50 times per second instead of opening 1,000 new ones
- A 'too many connections' database error under load is often a signal the pool size (or number of separate pools across app instances) exceeds the database's connection limit
Resources
Mastery checklist
- I can explain why opening a new connection per query is expensive
- I can configure a connection pool with an appropriate size for a given workload
- I can diagnose a 'too many connections' error as a pool-sizing or leak problem
- I can explain why connection pooling needs special handling in serverless environments