What is connection pooling and why does a database become saturated?
Published on 2026-10-26 by frfrand
Connection pooling explained: how to reuse connections, limits, queues, and PgBouncer.
A connection pool is a reusable set of connections to a database. It reduces the cost of opening and closing sessions continuously and allows controlling how many simultaneous connections the server receives.
A simple way to understand it
Imagine a company where each visitor needs a service desk. Building a new desk for each person would be absurd: it is better to keep a reasonable number of desks available and assign them as requests arrive.
How it works in practice
The application or an intermediate component maintains connections that can be reused. Tools like PgBouncer for PostgreSQL offer different pooling modes. The pool size should be adjusted to the load and server resources; one hundred processes with twenty connections each could exceed what the database supports.
What it does not solve and its limits
A pool does not make a poorly designed query faster nor avoid locks. If it is full, requests may wait and exhaust their timeouts. In addition, certain session-bound functions need special attention when using transaction pooling, because a request may receive a different physical connection.
How to apply it and check it without surprises
Check active connections, timeouts, query load, and PostgreSQL maximum parameters. Do not increase the pool indefinitely: more connections can increase memory consumption and worsen performance. Test what happens during restarts and network failures.
How does it appear in ArduMaker?
In projects with PostgreSQL and backends hosted on ArduMaker VPS, a properly sized pool can help handle concurrent traffic. Its configuration depends on the number of workers and the needs of each application.
Why too many connections worsen an application
Each active connection uses engine resources, even if it is not executing a query all the time. A fleet of workers that opens dozens of connections each can exhaust the available limit even with relatively low CPU. The pool allows coordinating that use, but if all operations block for too long there will still be waits.
A production detail
Schema migrations and long-lived connections may require different behavior than normal traffic. Before introducing PgBouncer, verify compatibility with transactions, prepared statements, and session state according to your client and chosen mode. Test under real concurrency and review timeouts.
How to calculate a starting point?
Count the open connections in the database during a normal hour and a peak hour. Compare that figure with the processes executing queries, transaction duration, and server limits. A pool that is too small causes waits; one that is too large can exhaust memory and increase contention. Choose a measurable initial configuration and review it under real load.
To remember
A connection pool is a reusable set of connections to a database. Understanding when it applies, how it fails, and what data to review is more useful than memorizing isolated commands.
To expand: PgBouncer: features and configuration.