Opening a Database Connection per Request Is a Latency Tax You Pay Forever
Key takeaway: Establishing a database connection involves real work — network setup, authentication, and handshaking — and doing it per request adds that cost to every request, while a connection pool reuses a small set of established connections and pays the setup cost only when a connection is first created.
Why a Fresh Connection per Request Is Expensive
Establishing a database connection is not free — it involves network round trips, authentication, and protocol handshaking, all of which take real time. When an application opens a fresh connection for every request and closes it when the request ends, it pays this setup cost on every single request, adding a fixed latency overhead to each one regardless of how fast the actual query is.
This overhead is especially wasteful because the connection is used briefly and then discarded, only to be re-established at the same cost for the next request — the application is repeatedly paying for setup work that could be done once and reused, and under load, the constant opening and closing of connections also adds load to the database server itself.
What a Connection Pool Does
A connection pool maintains a set of established connections that are reused across requests. When a request needs a connection, it borrows one from the pool, uses it, and returns it to the pool rather than closing it, so the next request can reuse the same connection without paying the setup cost again.
| Approach | Setup cost | Behaviour under load |
|---|---|---|
| New connection per request | Paid on every request | Constant overhead, plus churn on the database |
| Connection pool | Paid once per connection | Connections reused, minimal overhead |
The pool also manages the size of the connection set — a minimum number kept ready, a maximum that bounds how many connections the application will hold — which prevents the application from exhausting the database’s connection limit under load, a failure mode that a per-request approach can trigger when many requests arrive simultaneously.
The Pool Size Question
The pool size is a real tuning decision — too small, and requests queue waiting for an available connection, adding latency; too large, and the application holds more connections than the database can support, or holds connections that sit idle. The right size depends on the number of concurrent requests and how long each holds a connection, and it is worth measuring rather than guessing.
A common mistake is setting the pool size based on the number of application instances rather than the database’s total capacity — if many application instances each open a large pool, the combined total can exceed what the database can handle, which is why the pool size should account for the whole system, not just one instance.
When a Pool Is Not the Answer
A connection pool is the right answer for an application that makes many short database operations, where the setup cost would otherwise be paid repeatedly. For an application that makes very few, very long-lived database connections — such as a long-running batch process — a pool may add little value, since the setup cost is paid rarely anyway.
The Bottom Line
Use a connection pool for any application that makes many short database operations, since opening a fresh connection per request adds the connection setup cost to every request and creates churn on the database under load. Tune the pool size based on the database’s total capacity across all application instances, and measure the right size rather than guessing, since too small adds queueing latency and too large can exhaust the database’s connection limit.
