Database Connection Pooling in Production: Why More Connections Can Be Slower

Introduction#

Imagine your API is getting more traffic.

Everything works normally at first, but as traffic increases, requests start becoming slower.

Then you see an error like:

Timeout while waiting for a database connection

The first solution that comes to mind might be:

Increase the connection pool.

For example:

Before:
 
Pool size = 20
 
After:
 
Pool size = 200

That sounds reasonable.

More connections should allow more requests to access the database at the same time.

But in production, something surprising can happen:

More connections
      ↓
Higher database CPU
      ↓
More contention
      ↓
Slower queries
      ↓
Worse API latency

Increasing the connection pool can actually make your application slower.

The reason is simple:

A connection pool does not increase the capacity of your database. It only controls how many requests can use the database at the same time.

Understanding this difference is extremely important when running PostgreSQL in production.

In this article, we will understand how connection pools work, how to size them, how to detect saturation and connection leaks, and when tools like PgBouncer become useful.

What Is a Database Connection?#

Your application needs a connection before it can send queries to PostgreSQL.

A simplified request looks like this:

User Request
     |
     ↓
Application
     |
     ↓
Database Connection
     |
     ↓
PostgreSQL
     |
     ↓
Result

For example:

const result = await db.query("SELECT * FROM users WHERE id = $1", [userId]);

Behind this simple query, the application needs an available database connection.

Creating a completely new connection for every request would be inefficient.

Imagine doing this:

Request 1
   ↓
Create DB connection
   ↓
Run query
   ↓
Close connection
 
Request 2
   ↓
Create DB connection
   ↓
Run query
   ↓
Close connection

Opening database connections has overhead.

Instead, applications normally maintain a group of reusable connections.

That group is called a connection pool.

What Is a Connection Pool?#

A connection pool keeps several database connections open and reuses them between requests.

For example:

Application
 
      |
      ↓
 
Connection Pool
 
-------------------------
Connection 1
Connection 2
Connection 3
Connection 4
Connection 5
-------------------------
 
      |
      ↓
 
PostgreSQL

Suppose your pool has:

max connections = 5

Five requests can use database connections at the same time.

If a sixth request arrives while all connections are busy:

Request 1 → Connection 1
Request 2 → Connection 2
Request 3 → Connection 3
Request 4 → Connection 4
Request 5 → Connection 5
 
Request 6 → Waiting...

Once one connection becomes available:

Connection 3 released
        ↓
Request 6 gets Connection 3

This is the basic purpose of connection pooling.

It allows your application to reuse connections and control database concurrency.

Why Not Just Create a Huge Pool?#

This is where many production problems begin.

Suppose your API starts getting slow because requests are waiting for database connections.

You check your pool:

Pool size:     20
Active:        20
Waiting:       80

It is tempting to say:

Let's increase the pool to 200.

Now more requests can reach PostgreSQL simultaneously.

But PostgreSQL still has the same:

CPU
Memory
Disk
I/O capacity

You increased the number of workers asking the database to do work.

You did not increase how much work the database can actually handle.

Think of it like a supermarket.

Imagine there are four checkout counters.

Customers
    |
    ↓
-------------------------
Counter 1
Counter 2
Counter 3
Counter 4
-------------------------

Allowing 500 customers into the checkout area does not create more checkout capacity.

It just creates more competition and congestion.

Databases behave similarly.

More Connections Can Make PostgreSQL Slower#

Every PostgreSQL connection requires resources.

With many active connections, the database may have more:

Memory usage
 
CPU scheduling
 
Concurrent queries
 
Lock contention
 
Disk activity
 
Context switching

Suppose one application instance uses:

20 connections

That might work perfectly.

Then someone changes it to:

200 connections

The database suddenly has much more concurrent work.

Instead of improving throughput, you might see:

Database CPU → 95%
 
Query latency → increases
 
API latency → increases
 
Timeouts → increase

The important lesson is:

More database connections do not automatically mean more database throughput.

At some point, additional concurrency simply creates more competition for the same resources.

Pool Size Must Include Every Application Instance#

Another common mistake is looking at the pool size of only one application server.

Suppose your configuration says:

pool max = 20

Twenty connections might sound small.

But your production environment has:

10 application instances

Each instance creates its own pool.

So your real potential connection count is:

10 instances × 20 connections
 
= 200 database connections

The basic calculation is:

total possible connections
=
application instances × pool max

Now imagine your application automatically scales.

Normal traffic:
 
10 instances × 20
= 200 connections

During heavy traffic:

30 instances × 20
= 600 connections

Your autoscaling system increased application capacity, but it also tripled the possible database connections.

This can overload PostgreSQL unexpectedly.

Do Not Give Every Connection to the Application#

Your API is usually not the only thing connecting to PostgreSQL.

You may also have:

Application servers
Background workers
Database migrations
Monitoring systems
Scheduled jobs
Admin tools
Developers
Maintenance scripts

So if PostgreSQL allows:

500 connections

you should not configure your application fleet to consume all 500.

For example:

PostgreSQL max connections: 500
 
Application budget:         350
Workers:                     50
Monitoring / jobs:           20
Admin / maintenance:         30
Emergency capacity:          50

The exact numbers depend on your system.

The important idea is to leave capacity for things other than normal API traffic.

You especially want some connections available when production is having problems.

Otherwise, during an outage, even your admin tools may be unable to connect to the database.

There Are Two Different Places Requests Can Wait#

When debugging database performance, it is important to understand that waiting can happen in two places.

Request
   |
   ↓
Connection Pool
   |
   ├── Wait for connection
   |
   ↓
PostgreSQL
   |
   └── Execute / wait inside database

These are different problems.

Waiting for the Connection Pool#

Suppose:

Pool size: 20
 
Active connections: 20
 
Waiting requests: 100

The application cannot immediately get a database connection.

This is called pool acquisition wait.

Possible causes include:

Pool too small
 
Slow queries
 
Long transactions
 
Connection leaks
 
Traffic spike

Notice that a full pool does not automatically mean the pool is too small.

The database may simply be slow.

Waiting Inside PostgreSQL#

The second type of waiting happens after the application already has a connection.

For example:

Application
    |
    ↓
Gets connection immediately
    |
    ↓
Query reaches PostgreSQL
    |
    ↓
Waits 3 seconds

The query might be waiting because of:

High CPU
 
Slow disk
 
Missing indexes
 
Locks
 
Large queries
 
Too many concurrent queries

Increasing the pool in this situation usually makes things worse.

You are sending even more work into an already overloaded database.

Measure Pool Wait and Query Time Separately#

You should know how long requests spend:

Waiting for connection

and how long they spend:

Running database work

For example:

Request latency: 800 ms
 
Pool wait:       600 ms
Query time:      150 ms
Other work:       50 ms

This tells you that the query itself is reasonably fast.

The request mostly waits for a connection.

Compare that with:

Request latency: 800 ms
 
Pool wait:        10 ms
Query time:      740 ms
Other work:       50 ms

Now increasing the pool is probably not the solution.

The database query is the expensive part.

Useful metrics include:

Looking at these together gives you a much better picture than simply checking the connection count.

Keep Connections for as Little Time as Possible#

A database connection is a limited resource.

Your application should acquire one when it needs database work and release it as soon as that work finishes.

For example:

const client = await pool.connect();
 
try {
  await client.query("BEGIN");
 
  await performDatabaseWork(client);
 
  await client.query("COMMIT");
} catch (error) {
  await client.query("ROLLBACK");
 
  throw error;
} finally {
  client.release();
}

The important part is:

finally {
  client.release();
}

The finally block runs whether the operation succeeds or fails.

That makes sure the connection returns to the pool.

What Is a Connection Leak?#

Imagine your pool contains:

20 connections

A request takes one connection.

But because of a bug, the application never releases it.

Now:

Available connections = 19

Another request leaks one.

Available connections = 18

Eventually:

Available connections = 0

Now every new request waits.

Request
   |
   ↓
Connection Pool
   |
   ↓
No available connection
   |
   ↓
Wait...
   |
   ↓
Timeout

This is a connection leak.

It can be difficult to notice because the application may work normally for hours before enough connections have leaked to cause an outage.

Always make sure connections are released even when errors occur.

Do Not Hold Connections During Slow External Work#

Consider this code:

const client = await pool.connect();
 
try {
  await client.query("BEGIN");
 
  await client.query("UPDATE orders SET status = 'processing' WHERE id = $1", [
    orderId,
  ]);
 
  await callExternalPaymentAPI();
 
  await client.query("COMMIT");
} finally {
  client.release();
}

There is a problem.

The application holds the database connection while waiting for:

External Payment API

Suppose that API takes:

3 seconds

Your connection is occupied for those three seconds even though PostgreSQL is doing nothing.

With enough requests:

20 connections
      ↓
20 requests waiting on external APIs
      ↓
Pool completely occupied
      ↓
New requests cannot access PostgreSQL

As a general rule:

Do not hold a database connection or transaction while waiting for unrelated slow work.

Keep transactions focused on database operations and keep them short.

Long Transactions Are Dangerous#

A connection being idle does not always mean it is harmless.

One particularly important PostgreSQL state is:

idle in transaction

This means a transaction was opened but has not been completed.

For example:

BEGIN;
 
UPDATE orders
SET status = 'processing'
WHERE id = 123;
 
-- application waits here for a long time

The transaction is still open.

Long transactions can hold locks and interfere with PostgreSQL's normal cleanup behavior.

So monitoring should include:

Transaction age

not only:

Query execution time

Pool Timeouts Protect Your Application#

Suppose your database can safely process a limited amount of concurrent work.

Traffic suddenly increases.

Without limits, requests can continue building up:

Database overloaded
      ↓
100 waiting requests
      ↓
500 waiting requests
      ↓
2,000 waiting requests
      ↓
Memory increases
      ↓
Application becomes unhealthy

Instead, use bounded waiting.

For example:

Pool acquisition timeout: 500 ms
 
Statement timeout:        2 seconds
 
Request timeout:          3 seconds

The exact numbers depend on your application.

The idea is that requests should not wait forever.

A timeout allows the system to say:

The database cannot handle more work right now.

instead of building an unlimited queue.

Timeouts should also fit into your overall request deadline. The retry-storm guide explains why retries, timeouts, and downstream capacity need one coordinated budget.

What Is PgBouncer?#

As your system grows, you may have many application instances.

For example:

20 API instances
10 workers
5 scheduled-job processes

Each process may maintain its own connection pool.

This can create hundreds or thousands of client connections.

PgBouncer sits between your applications and PostgreSQL.

Applications
     |
     ↓
Application Connection Pools
     |
     ↓
PgBouncer
     |
     ↓
PostgreSQL

Your applications can connect to PgBouncer while PgBouncer manages a smaller number of actual PostgreSQL connections.

Conceptually:

500 application connections
 
        ↓
 
     PgBouncer
 
        ↓
 
100 PostgreSQL connections

This can be very useful when you have many application processes or frequently changing instances.

PgBouncer Does Not Make PostgreSQL Unlimited#

PgBouncer solves an important connection-management problem.

But it does not magically increase database CPU or query capacity.

Think about it like this:

Application
     |
     ↓
Application Pool
     |
     ↓
PgBouncer Queue
     |
     ↓
PostgreSQL

If PostgreSQL can only process a certain amount of work efficiently, PgBouncer cannot change that.

It helps manage and reuse connections more efficiently.

You still need reasonable limits.

Avoid configuring:

Application pool = huge
 
PgBouncer pool = huge
 
PostgreSQL connections = huge

and expecting the performance problem to disappear.

You have simply moved the queue.

PgBouncer Transaction Pooling#

One common PgBouncer mode is transaction pooling.

A PostgreSQL server connection is assigned while a transaction is running.

When the transaction finishes:

BEGIN
  ↓
Queries
  ↓
COMMIT
  ↓
Connection returned

the server connection can be reused by another client.

This makes connection usage efficient.

However, your application should not assume that it owns the same PostgreSQL session forever.

Some session-level features therefore require extra care, including things such as:

Temporary tables
 
Session variables
 
Some prepared statement setups
 
Session-level advisory locks

Before enabling transaction pooling, verify that the database features and driver behavior used by your application are compatible with it.

Autoscaling Can Create a Connection Storm#

Suppose your normal production environment has:

5 application instances
 
Pool size = 20

Maximum potential connections:

5 × 20 = 100

Traffic suddenly increases and Kubernetes or another platform scales your application to:

30 instances

Now:

30 × 20 = 600 connections

Your application scaling system just created hundreds of additional potential database connections.

This is why database capacity must be considered when configuring autoscaling.

Scaling the API layer is easy.

Scaling the database is usually harder.

Serverless Applications Need Extra Care#

Serverless platforms can make connection management even more challenging.

Imagine hundreds of functions starting at approximately the same time.

If every function creates:

10 database connections

then:

200 functions × 10
 
= 2,000 possible connections

The database can become overloaded even if each individual function seems reasonable.

For serverless environments, you may use:

Provider connection proxy
 
PgBouncer
 
Database-aware serverless drivers

depending on your database provider and deployment environment.

Where supported, reuse connections across warm function invocations rather than opening unnecessary new connections for every request.

How to Diagnose Connection Saturation#

PostgreSQL exposes connection information through:

pg_stat_activity

A simple query is:

SELECT state, COUNT(*)
FROM pg_stat_activity
GROUP BY state;

This helps show how database sessions are being used.

You might see states such as:

active
 
idle
 
idle in transaction

But connection count alone is not enough.

Also investigate:

Long-running queries
 
Long transactions
 
Lock waits
 
Database CPU
 
Query frequency
 
Pool acquisition time
 
Waiting requests

For example, imagine your pool suddenly becomes saturated.

It is easy to conclude:

We need more connections.

But perhaps one important query changed from:

20 ms

to:

2 seconds

Connections now remain occupied much longer.

The pool fills up as a result.

The real problem is not:

Pool too small

It is:

Query became slow

In that situation, increasing the pool may hide the problem temporarily while increasing pressure on PostgreSQL.

The PostgreSQL query-plan guide explains how to investigate slow queries using EXPLAIN ANALYZE.

How Should You Choose a Pool Size?#

There is no universal number such as:

pool size = 100

that works for every application.

Pool size depends on things like:

Database CPU
 
Available memory
 
Query speed
 
Transaction duration
 
Application instance count
 
Background workers
 
Traffic patterns
 
Database workload

Start with a conservative number.

Then load-test the system.

For example:

Test 1
 
10 app instances
10 connections each
 
Total = 100

Measure:

Throughput
P95 latency
P99 latency
Database CPU
Pool wait time
Query latency
Lock waits

Then test another configuration:

Test 2
 
10 app instances
15 connections each
 
Total = 150

Compare the results.

You may eventually reach a point where:

Connections ↑
 
Throughput stays similar
 
Latency ↑
 
Database CPU ↑

At that point, adding connections is no longer helping.

Your goal is not:

Maximum number of connections

Your goal is:

Enough concurrency to keep the database productive
without overwhelming it.

A Practical Example#

Suppose you have:

PostgreSQL max connections: 300
 
Application instances:      10
Workers:                      5

You decide to reserve:

50 connections

for:

Administration
Monitoring
Migrations
Maintenance
Emergency access

That leaves:

250 connections

But that does not mean every application should immediately consume all 250.

You might begin with:

API:
 
10 instances × 15
= 150 connections
 
 
Workers:
 
5 workers × 10
= 50 connections
 
 
Reserved:
 
50 connections

Total:

150 + 50 + 50
 
= 250

Then load-test and monitor the database.

The important part is that pool sizing becomes a capacity decision for the entire system, rather than a random configuration value inside one application.

Common Mistakes#

Increasing the Pool Whenever Requests Wait#

Seeing requests waiting for connections does not automatically mean:

Increase pool size

First ask:

Why are connections busy?

Maybe:

A query became slow
 
Transactions became longer
 
Connections are leaking
 
Database CPU is saturated
 
Traffic suddenly increased

Fix the underlying problem first.

Ignoring Application Instance Count#

This configuration:

pool max = 30

looks small.

But:

40 instances × 30
 
= 1,200 possible connections

Always calculate connection capacity across the entire fleet.

Holding Connections During Network Calls#

Avoid:

Open transaction
      ↓
Update database
      ↓
Call external API
      ↓
Wait 5 seconds
      ↓
Commit transaction

Keep transactions short whenever possible.

Using Huge Pools With PgBouncer#

PgBouncer helps manage connections.

It does not remove database capacity limits.

Use deliberate limits at:

Application pool
 
PgBouncer
 
PostgreSQL

Looking Only at Connection Count#

A database with:

100 connections

might be healthy.

Another database with:

30 connections

might be overloaded.

Connection count has meaning only when combined with:

CPU
Query latency
Lock waits
Transaction duration
Pool waiting
Throughput

Production Checklist#

Before changing your connection pool, check:

• Calculate connections across all application instances.
• Include workers and background jobs.
• Reserve connections for administration and maintenance.
• Measure pool acquisition time.
• Measure query execution time separately.
• Monitor active and idle connections.
• Monitor long-running transactions.
• Release connections in finally.
• Keep transactions short.
• Avoid external network calls while holding connections.
• Configure pool acquisition timeouts.
• Configure sensible statement timeouts.
• Check for slow queries before increasing the pool.
• Test PgBouncer compatibility before using transaction pooling.
• Consider database connections when configuring autoscaling.
• Load-test PostgreSQL, not only your API servers.

Final Architecture Thinking#

Think about connection pooling like this:

Incoming Requests
       |
       ↓
Application
       |
       ↓
Connection Pool
       |
       ↓
Controlled Database Concurrency
       |
       ↓
PostgreSQL

The pool protects the database from receiving unlimited concurrent work.

It should not become:

Incoming Requests
       |
       ↓
Huge Connection Pool
       |
       ↓
Thousands of Concurrent Queries
       |
       ↓
Overloaded PostgreSQL

When your system grows further, the architecture may become:

Application Instances
        |
        ↓
Application Pools
        |
        ↓
PgBouncer
        |
        ↓
Controlled PostgreSQL Connections
        |
        ↓
PostgreSQL

The important word is:

Controlled

More concurrency is useful only while the database has capacity to process it.

Conclusion#

Database connection pooling sounds simple:

Keep connections open
      ↓
Reuse them
      ↓
Avoid connection setup overhead

But in production, pool sizing becomes a capacity problem.

Increasing:

20 connections
      ↓
200 connections

does not make PostgreSQL ten times faster.

It may actually make the database slower by increasing concurrent work, CPU pressure, lock contention, memory usage, and I/O.

Instead, think about the entire system:

How many application instances exist?
 
How many workers exist?
 
How many connections can each process create?
 
How long are connections held?
 
How long do queries take?
 
How long do transactions stay open?
 
How much concurrency can PostgreSQL actually handle?

Then size the pool based on measurements.

Remember:

A connection pool does not create database capacity. It controls access to database capacity.

A good production pool keeps PostgreSQL busy without overwhelming it, makes overload visible through bounded queueing and timeouts, and leaves enough capacity for important operational work.

References#

• Resource consumption settings — PostgreSQL
• PgBouncer configuration
• Connection pooling — node-postgres