Connection Pooling: The Quiet Killer of SaaS Performance

What you actually need to know

• Pool exhaustion produces incidents that look like database problems.
• Total connections across all servers should fit comfortably under Postgres max_connections.
• PgBouncer is the standard for serverless Postgres workloads.
• Transaction pooling mode is the right default.
• Monitor checkout time and queue depth as the warning signals.

The core argument

Connection pool incidents are some of the most common production issues in SaaS and some of the hardest to diagnose without context. The pattern is consistent. The application gets busy. Requests slow down. The team looks at the database. The database CPU is fine. The query latency is fine. The team is confused. The actual problem is that the application has run out of connections in its pool and new requests are waiting.

The fix is sizing the pool correctly and adding visibility into pool health. The pool should be large enough to handle the application's concurrency. The total connections across all application servers should fit comfortably under the database's max_connections. The monitoring should expose pool checkout time and queue depth.

The mistake teams make is using the framework default pool size and never measuring. The default is rarely right for the application's actual load. A pool of 10 is too small for an app server that handles 200 concurrent requests. A pool of 200 is too large if the database only allows 100 connections and you have five app servers.

Serverless workloads compound the problem. Each serverless instance opens its own connection. Without a pooler in front of the database, the database hits its connection limit immediately. PgBouncer or an equivalent connection pooler is required. The pooler maintains a small pool of real connections and serves many more application connections from that pool.

The configuration that works

How much does this cost

Features the connection setup must have

• Pool size set deliberately, not framework default.
• Acquisition timeout set so requests fail rather than hang forever.
• Connection lifetime set to prevent stale connections.
• Monitoring on checkout time, queue depth, and errors.
• A pooler in front of the database for serverless workloads.
• A documented connection budget across services.
• An alarm on pool saturation.

Expert opinion

Connection pooling is one of those topics that engineers do not think about until they have an incident. The teams that have had the incident never forget. The teams that have not had the incident often have pool settings that will cause one eventually. The right sizing is mechanical. The monitoring is cheap. The operational pain it prevents is real.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A client SaaS was experiencing intermittent latency spikes that the team had attributed to database performance. They had scaled up the database instance twice without improvement. The founder asked me to look.

The metrics showed pool checkout times of 800 milliseconds during the spikes. The database itself was idle. The pool was undersized for the load. The application had a pool size of 10 per server and was running 25 concurrent requests on most servers. Requests were queueing for connections.

We raised the pool size to 40 per server and added PgBouncer in front of the database to manage the total connection count. The latency spikes disappeared. The database scaling that had been done was unnecessary. The team adopted pool monitoring as a standard observability metric.

For more on the related work, see connection pooling why defaults are wrong for most stacks and PostgreSQL performance at scale the tweaks that move the needle.

Common mistakes teams make

1. Using the framework default pool size.
2. No pooler in front of Postgres for serverless workloads.
3. Pool size larger than the database can handle.
4. No monitoring on checkout time.
5. No acquisition timeout. Requests hang forever.
6. Session pool mode where transaction would have worked.
7. Treating database performance as the problem when the pool is exhausted.
8. No connection budget across services.

A 30 day plan to fix connection pooling

1. Week one. Measure current pool checkout time and queue depth.
2. Week two. Size the pool correctly for the concurrency.
3. Week three. Add PgBouncer or equivalent if serverless.
4. Week four. Wire monitoring. Set alarms on saturation.

For more on the related work, read connection pooling why defaults are wrong for most stacks and PostgreSQL performance at scale the tweaks that move the needle. On the broader scaling side, scaling from one thousand to one hundred thousand users the invisible database bottlenecks is the natural next read.