Database Connection Churn

When an application repeatedly opens and closes database connections at high rate: due to missing connection pooling, misconfigured pool recycling, or serverless function architecture: the database server is overwhelmed with connection establishment overhead. PostgreSQL forks a new backend process per connection (10–50ms overhead each), and at high connection rates the server hits its max_connections limit and rejects new connections with "too many clients already", even though the database itself has idle capacity for query execution.

PostgreSQL uses a process-per-connection model: each new client connection causes the postmaster to fork a new backend process. This fork takes 10–50ms on modern hardware and consumes approximately 5–10 MB of memory per connection for the process overhead. The actual query execution does not begin until the fork completes, TLS is negotiated, and authentication is verified: a total setup cost of 15–80ms per new connection.

Without connection pooling, an application handling 1,000 requests/second that opens a new connection per request generates 1,000 new connections/second. Each setup takes 15–80ms, meaning the connection setup itself becomes a latency component comparable to the query execution time. At 1,000 connections/second, PostgreSQL may have 100–500 connections in the setup phase simultaneously, consuming 500 MB to 2.5 GB of memory for process overhead alone before any query bytes are transferred.

The max_connections limit (default 100, commonly set to 200–500 in production) caps the total number of simultaneous connections. When the limit is reached, new connection attempts receive "FATAL: too many connections" and fail immediately. In a high-churn scenario, even with a max_connections of 500, the combination of active queries, connections in the setup phase, and connections in teardown phase can exceed the limit. The database appears to be at capacity even though actual query throughput is a fraction of hardware capability.

Serverless functions exacerbate this pattern. Each Lambda invocation opens its own connection on cold start and closes it when the invocation ends (or keeps it open for warm reuse, but Lambda concurrency limits mean hundreds of independent function instances may each hold their own connection). 500 concurrent Lambda invocations each with their own PostgreSQL connection consumes 500 connection slots : exceeding default max_connections on a modest RDS instance.

PgBouncer in session mode with pool_size=20 intercepts all 500 concurrent connection requests, queues or rejects those beyond pool_size, and multiplexes 20 real PostgreSQL connections. The 20 real connections are long-lived, eliminating the per-request fork overhead entirely. Query execution time decreases because the connection is ready immediately on pool acquisition.