For Microsoft.Data.SqlClient, connection pooling is enabled by default: configure it through the connection string, open a logical connection only when database work is ready, and dispose it as soon as that work ends. The pool then reuses physical connections. The main safeguards against exhaustion are consistent connection configuration, short-lived connections and transactions, and sizing the per-pool limit against database capacity.
How ADO.NET connection pooling works
With pooling enabled, an application can create and dispose logical SqlConnection objects without establishing a new physical database connection for every operation. When a connection is closed or disposed, SqlClient can return its physical connection to a matching pool for reuse, provided transaction context allows it. See Microsoft’s SQL Server connection pooling documentation.
Use the pattern often summarized in Microsoft’s documentation as “Open late, dispose early, and let the pool manage physical connections.” Do not keep one process-wide SqlConnection open as a substitute for pooling. Open connections near the database operation, and close or dispose them promptly afterward.
Configure SqlClient pooling options
Pooling controls are SqlClient connection options. Microsoft’s documented defaults for Microsoft.Data.SqlClient are below; they are provider defaults, not a universal tuning recommendation. See Connection options for Microsoft.Data.SqlClient.
#1 Best Overall
| Option | Documented default | Effect |
|---|---|---|
Pooling |
true |
Enables connection pooling. |
Min Pool Size |
0 |
Sets no minimum number of physical connections to retain through this setting. |
Max Pool Size |
100 |
Caps physical connections in each individual pool. |
Connect Timeout |
15 seconds |
Limits time to establish a connection or wait for an available pooled connection when the pool is full. |
Load Balance Timeout (also called Connection Lifetime) |
0 |
Disables age-based discarding. |
To set options in code, use SqlConnectionStringBuilder rather than assembling a connection string by concatenating values:
var builder = new SqlConnectionStringBuilder(existingConnectionString)
{
Pooling = true,
MinPoolSize = 0,
MaxPoolSize = 100,
ConnectTimeout = 15
};
string connectionString = builder.ConnectionString;The values shown retain the documented defaults; change them only when your workload and database capacity justify doing so. The builder helps set and validate connection options. Microsoft’s SqlConnection.ConnectionString documentation cautions against placing user-supplied values directly into a connection string.
Rank #2
Keep connections in the same pool
SqlClient selects a pool based on connection configuration. Exact connection-string text matters: even changing keyword order can result in a different pool despite equivalent effective settings. Authentication identity, credentials or token handling, application name, and other configuration can also affect pool selection. Transaction-enlisted connections may be held in transaction-specific subdivisions.
- Use one canonical connection configuration rather than constructing variations for individual requests.
- Avoid changing fields such as
Application Nameper request; variation can fragment reuse. - Keep credentials and authentication handling consistent with the intended pool boundaries.
Each pool has its own maximum, so a Max Pool Size of 100 does not mean the entire application can open only 100 connections. Multiple pools and multiple application instances can raise the aggregate possible number of database sessions.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Apply the settings in an ASP.NET Core app
The pooling options belong to the SqlClient connection configuration used by the application. The Microsoft material cited here documents provider behavior and connection-string options; it does not establish a current ASP.NET Core-specific recipe for storing settings in appsettings.json, environment variables, a secret provider, or dependency injection. Follow the configuration guidance for the ASP.NET Core version and hosting environment you use rather than copying older web.config examples from general connection-string documentation.
Wherever the application obtains its connection string, keep its effective configuration stable between operations that should share a pool. Use SqlConnectionStringBuilder when constructing or modifying the SqlClient options, and avoid mixing per-request data into the connection string.
Rank #4
Prevent and diagnose pool exhaustion
When a pool reaches its maximum, subsequent opens wait for an available connection up to the configured Connect Timeout. If one does not become available in time, connection acquisition fails with a timeout. Increasing the maximum before identifying why connections are unavailable can simply move the pressure to SQL Server. Microsoft’s SqlClient Troubleshooting Guide covers connection-related diagnostics.
- Check disposal on every path. Inspect code for connections, readers, and transactions that remain open beyond their work. Ensure disposal also happens when operations fail.
- Look for fragmented pools. Compare the connection configurations used by callers, including keyword order and variable fields such as application name.
- Find long-held connections. Review slow queries and transactions that keep a connection checked out longer than necessary.
- Estimate total capacity. Account for the maximum per pool, the number of distinct pools, and all service replicas; compare that aggregate with what the database can support.
- Change limits only with evidence. After correcting leaks and unnecessary hold time, consider a measured pool-size change if legitimate concurrent demand still exceeds the limit.
Account for ambient transactions and pool clearing
With Enlist=true (the default), connections opened within an ambient System.Transactions transaction automatically enlist. Closing a connection while that transaction remains active may leave it in a transaction-specific subdivision until the transaction completes, making it unavailable for general reuse in the meantime. Keep ambient transactions bounded and complete them explicitly.
Recommended Free Tools
SqlClient can clear a pool automatically after certain recognized fatal errors, such as failover. The provider also exposes ClearPool for a pool associated with a connection configuration and ClearAllPools to clear all SqlClient pools in the process or application domain. Clearing idle and checked-out connections leads to new physical logins on later opens. Use these APIs for a known configuration or credential boundary, not as recurring cleanup or a replacement for correct disposal. See Microsoft’s ADO.NET Provider for SQL Server pooling documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
