Connection pooling
Also called connection pool, database pooler.
Keeping a set of open database connections and sharing them across requests, instead of opening a new connection for each one.
Last updated
What it is.
Opening a database connection takes time and memory on the database server, and databases allow only so many at once. A pool keeps some connections open and lends one to each request, then takes it back. The pool can live inside the app or in a separate pooler service in front of the database.
Poolers often work in different modes, such as one connection per transaction or per session. The mode decides which database features, like session settings or prepared statements, still work.
Why it matters
Without pooling, a traffic spike or a burst of serverless instances can open more connections than the database allows, and the whole app goes down. Pooling keeps the database steady and cuts the time each request spends waiting.
In a product build
We size the pool to what the database can handle, not what the app might want, use a pooler for serverless and autoscaling apps, and set timeouts so a stuck query cannot hold a connection forever. Pool usage is a dashboard metric from the start.
Common mistakes.
- 01
Each app instance opening a large pool, so the total exceeds the database limit.
- 02
Using session features in transaction mode and getting odd bugs.
- 03
Long-running transactions that keep connections out of the pool.
Related terms.
- Read replicaA read-only copy of a database that is kept in sync with the main database and takes read queries off it.
- ServerlessA cloud model where the provider runs your code on demand and manages the servers, and you pay for what you use rather than for idle machines.
- Cold startThe extra delay when a serverless function or a new server instance has to start up before it can handle a request.
- AutoscalingAutomatically adding or removing computing capacity, such as servers or containers, as the load on a system goes up or down.
- ShardingSplitting one large dataset across several databases, called shards, by a key such as customer ID, so each shard holds only part of the data.
