Why pool: the cost of creating a connection

A junior service opens a fresh Postgres connection for every request, runs one quick SELECT, and closes it. The query takes 1 ms; the request takes 35. The missing 34 ms are pure setup: a TCP handshake, a TLS handshake, and the database authenticating the user and forking a backend process — every single time, thrown away after one query. Under load the database spends more CPU creating and destroying connections than answering them. Nobody wrote a slow query. They wrote a fast query wrapped in an expensive ritual, repeated on every request.

A connection is expensive to create

To a beginner a database connection looks free — call connect(), get an object. Underneath, opening one is a chain of slow steps:

• TCP handshake — a round trip to establish the socket (one RTT before any bytes flow).
• TLS handshake — encryption setup, 2 round trips on TLS 1.3, 3 on TLS 1.2; on a link with real latency this alone is tens to hundreds of milliseconds.
• Authentication — the database verifies credentials, often with its own challenge/response round trip.
• Backend allocation — Postgres forks a dedicated OS process per connection; MySQL spawns a thread. That process reserves memory (~2–3 MB of shared/admin memory before it runs a single query).

So a connection is not a cheap handle — it is a TCP socket plus a TLS session plus a live server-side process. Creating and tearing one down per request means paying all of that for one query’s worth of work.

A pool amortises the cost

A connection pool is a small, long-lived set of already-open connections kept ready. Instead of connect → query → close, the flow becomes:

1. Check out (acquire/borrow) a ready connection from the pool.
2. Run your query on it.
3. Return (release) it to the pool — not closed, just marked free for the next request.

The expensive handshakes happen once, when the pool fills, then those same connections are reused thousands of times. This is amortisation: a fixed setup cost spread across many uses until the per-request share is negligible. A request now pays ~0 ms of setup instead of ~34, and the database stops burning CPU on connection churn.

A pool is also a limit

Reuse is the obvious benefit, but the pool’s second job matters just as much: it is a bound. A pool of size 20 means at most 20 connections ever exist from this service to the database, no matter how many requests arrive. That cap is a feature — it protects the database, which can only handle so many backends before it falls over (Postgres defaults to max_connections = 100). Without a pool, a traffic spike of 5,000 concurrent requests would try to open 5,000 connections and the database would reject them with “too many clients.” The pool turns unbounded demand into a fixed, survivable number — the same bounded-concurrency idea from the last unit, applied to the most expensive downstream resource a backend has.