← Back to Blog
PostgreSQL1 minApr 18, 2024

Connection pools: why more connections can make your API slower

How to recognize PostgreSQL saturation and design a test for sizing a connection pool.

The misleading intuition#

If one connection performs work, one hundred connections should perform one hundred times more. In a database, parallel work competes for CPU, memory, locks and storage. Past a certain point, every additional connection increases waiting.

Design the experiment#

Run the same load with increasing pool sizes and record throughput, latency and server utilization.

pool: 5, 10, 20, 40, 80
clients: 200
duration: 5 minutes

Saturation signals#

  • Throughput stops increasing.
  • p95 latency rises quickly.
  • CPU or I/O remains near its limit.
  • Lock wait time grows.

Configure with headroom#

The right value is usually before the absolute peak. Leave capacity for migrations, internal tasks and traffic variation. When the application has many instances, calculate total connections rather than one instance’s pool.

Conclusion#

The pool protects the database and applies backpressure. Its purpose is not to open as many connections as possible, but to keep the system in an efficient and predictable range.