DevOps

Database Connection Pool Sizer

Calculate the connection pool size your application actually needs from concurrency and query time, and see why a larger pool usually makes throughput worse rather than better.

Last reviewed by the Radiatus Cloud team

Pool sizing appears here.

Want this automated for your stack?

We build CI/CD, Kubernetes & IaC pipelines that scale.

Talk to an engineer

Bigger pools are slower

The intuition that more connections means more throughput is wrong for databases, and the reason is that a database server executes queries on a finite number of cores with a finite number of disks. Connections beyond that number do not run in parallel; they queue inside the database while consuming memory, a backend process and a share of the lock manager. The HikariCP project documented this with a benchmark where reducing a pool from 2048 to 96 connections cut response time from 100 milliseconds to 3.

The formula and Little's Law

The widely used starting point is cores times two plus effective spindle count, which for a modern eight core server with SSD storage gives roughly twenty connections. The other approach is Little's Law: the concurrency you need equals arrival rate times service time. Two hundred requests per second each holding a connection for ten milliseconds needs two connections, not two hundred. Most applications are configured for the arrival rate rather than the concurrency, which is how a pool ends up a hundred times larger than it needs to be.

Total connections across every client

The number that matters to the database is the sum of every pool on every instance, plus background jobs, plus migrations, plus whatever a monitoring agent opens. Twenty instances with a pool of fifty each is a thousand connections against a Postgres default max_connections of one hundred. Each Postgres backend also costs several megabytes of memory before it does any work, which is why a connection pooler such as PgBouncer exists and why it is usually the right answer above a few hundred clients.

Related tools

Frequently Asked Questions

What size pool should I start with?

Around cores times two on the database server, so roughly 16 to 24 for an 8 core instance, divided across your application instances. Then measure: if the pool is never exhausted, it is large enough, and if queries queue inside the database, it is too large.

Why does a larger pool reduce throughput?

Because the database executes queries on a fixed number of cores. Extra connections queue inside the database rather than running in parallel, while each one consumes memory and adds contention in the lock manager. The queueing simply moves from your application to a more expensive place.

How do I use Little’s Law here?

Required concurrency equals arrival rate times the time each request holds a connection. 500 requests per second holding a connection for 20 ms needs 10 concurrent connections. Sizing for the arrival rate instead is how pools end up a hundred times too large.

When do I need PgBouncer or a similar pooler?

When the total connection count across all clients approaches the database limit, or when you have many short lived clients such as serverless functions. Transaction pooling mode multiplexes many clients onto few server connections, at the cost of not supporting session level features.

What about long running queries and transactions?

They hold a connection for their whole duration, so a single slow report can consume a large share of a small pool. Give analytical work a separate pool or a read replica so it cannot starve the transactional path.

Privacy & Security

Everything runs in your browser; nothing is uploaded.

Data: None
Client-side-Side
Active
v1.0

How to Use

Enter your request rate, query time and instance count to size the pool per instance and in total.

Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.