MaxPoolSize vs. Connection Lifetime: Which Better Prevents Intermittent Pool Exhaustion?

Short answer

Neither setting prevents intermittent exhaustion, and raising MaxPoolSize is the worse first move when a leak is suspected. The first line of defense is confirming that connections are actually being returned to the pool. If you must pick a tuning knob, a non-zero Connection Lifetime is the safer experiment, but understand that it recycles idle connections — it does not free connections that are still checked out, so it cannot fix a leak either.

Confirmed facts vs. likely explanation

Confirmed behavior (Microsoft.Data.SqlClient / System.Data.SqlClient, .NET 6+):

• Max Pool Size caps physical connections per pool (per unique connection string, per process). Default is 100. Raising it does not return leaked connections; it only delays the timeout and increases SQL Server memory and scheduler load.
• Connection Lifetime retires a pooled connection on check-in if its age exceeds the value. It never touches in-use connections.
• The classic Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool error almost always means connections are checked out longer than expected — missing Dispose/using, fire-and-forget async, or a long-running query holding a connection.

Likely explanation for "intermittent": burst traffic coinciding with a slow code path that holds connections slightly too long, so the pool drains only under load. That pattern looks like a capacity problem but is a residency-time problem.

Answering your three questions

1. First line of defense: neither. Audit disposal first (await using var conn = ... on every path, including exceptions and early returns). If you need an immediate mitigation while investigating, a moderate Connection Lifetime (e.g., 300–600s) is lower-risk than raising MaxPoolSize, because it won't increase peak server load.
2. Short lifetime under burst: each retired connection must be re-established — TCP/TLS handshake plus login — adding tens to hundreds of milliseconds per checkout. Under bursts this churn stacks: many connections expire together, then many reconnect together, producing latency spikes. Very short values (under ~60s) are usually counterproductive.
3. Combined resource effect: high MaxPoolSize + short lifetime is the worst combination — maximum server-side connection overhead plus maximum reconnect churn. Low pool size + long lifetime minimizes churn but leaves you exposed to leaks and stale connections. Neither combination compensates for unreturned connections.

What to measure before changing anything

Capture the SqlClient performance counters (or dotnet-counters metrics for Microsoft.Data.SqlClient.EventSource):

dotnet-counters monitor --process-id <pid> \
  --counters Microsoft.Data.SqlClient.EventSource

Watch active and pooled connections versus your MaxPoolSize during a burst:

• Pooled connections pinned at the max while active connections keep climbing → leak or slow checkout path. Tune nothing; fix the code.
• Pool well below the max but checkout waits still high → churn/latency problem; a longer, not shorter, lifetime may help.

On the server, correlate with sys.dm_exec_connections to see whether physical sessions grow in step with the client pool.

One diagnostic that changes the recommendation

During an exhaustion event, does NumberOfActiveConnections keep growing while pooled connections sit at MaxPoolSize? If yes, this is a leak — both settings are irrelevant until it's fixed. If instead connections are returned promptly but stale (e.g., after a failover or firewall idle-timeout reset), then a Connection Lifetime in the 300–900s range is the right tool, and pool size can stay at default.

Practical recommendation

1. Fix disposal everywhere; this resolves the majority of intermittent exhaustion cases.
2. Leave MaxPoolSize at 100 unless measurements show genuine, leak-free demand above it.
3. Set Connection Lifetime only to handle stale connections, and keep it in the minutes range, not seconds.
4. Re-run a controlled burst test after each change and compare pool wait time, not just error counts.

Version note: behavior described applies to current SqlClient providers on .NET 6+; counter names differ slightly between System.Data.SqlClient and Microsoft.Data.SqlClient. Verify against your provider version before relying on specific metric names.