Connection pools: real timings

A connection pool exists so you do not pay for opening a connection on every request. Measured on loopback over 200 sequential requests, a fresh connection costs 0.598 ms and one reused from a keep-alive pool 0.191 ms: three times as much, with the server doing nothing different.

What opening a connection costs

Opening a connection means at least three steps: the TCP handshake, authentication and session setup. PostgreSQL adds a process per connection, so the cost is not only network but memory and scheduler time. The PostgreSQL 18 documentation, read on 1 November 2026, notes that max_connections is typically 100 and that raising it increases shared memory allocation: a pool is not optional, it is how you stay under that number.

The numbers, and what they mean

The measured saving is 0.407 ms per request on loopback, where the network adds no latency. On a link with 20 ms round-trip time the same handshake costs at least three times that latency, so the gap grows by an order of magnitude. The burst shows it plainly: 26.6 ms against 108.2 ms, four times less time for the same work.

How many connections to keep open

Start from the cores available to the database and multiply by the application instances: the total must stay below max_connections minus the superuser slots, which default to three. A pool of 20 connections across five instances is already a hundred connections, the limit of a default PostgreSQL. The command below shows the ceiling and the real usage.

psql "$DATABASE_URL" -Atc "show max_connections; show superuser_reserved_connections;"
psql "$DATABASE_URL" -Atc "select state, count(*) from pg_stat_activity group by state order by 2 desc;"

A pool is not an infinite queue

When every connection is busy, requests wait. Without an acquisition timeout the wait grows past the client timeout, and the service looks slow instead of looking saturated. Set a maximum wait shorter than the endpoint timeout, a statement timeout and a metric on waits: pool latency must be visible before it becomes an incident.

The limit: loopback has no latency

This measurement is the floor, not the ceiling. On loopback the round-trip time is close to zero, so the pool gains little; on a real network it gains much more, but no pool shortens a slow query. If a query takes two seconds, the connection stays busy for two seconds: a pool spreads the wait, it does not remove it. In a serverless environment the shape changes, because each instance opens its own connections and the pool has to move to the database.

Where to start