阅读中文版本

Database Connection Multiplexing

A connection pooler multiplexes many short-lived client connections onto a small set of backend sessions, protecting databases that pay a cost per connection.

Definition

Connection multiplexing is the practice of routing many application connections through a middle tier that maintains a much smaller number of real database sessions, reusing them as clients become idle.

It is essential for serverless platforms and any fleet where thousands of short-lived processes would otherwise exhaust the database’s connection limit. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

A pool keeps sessions open and hands them to callers in turn, while a transaction-capable multiplexer assigns a real session only for the duration of a transaction and returns it afterward.

Session-level state such as temporary tables, advisory locks, set variables, or prepared statements travels with the physical session, so a shared session can leak state between unrelated callers.

Trade-offs and alternatives

The right pool size is bounded by database CPU and storage, not by application thread count, and pushing beyond that turns latency into queueing rather than throughput. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that pooling and multiplexing are the same thing. Another is that multiplexing is transparent to every database feature. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to multiplexing connections that hold session state across statements and to pointing every client directly at the database and increasing max connections. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Autovacuum and Dead Tuple Reclamation, LATERAL Joins, Upsert with INSERT … ON CONFLICT.