For Microsoft.Data.SqlClient in ASP.NET Core, connection pooling is enabled by default: configure the provider through the connection string, open a logical connection only when database work is ready, and dispose it as soon as that work finishes. The pool—not a process-wide connection you keep open—reuses physical connections. The defaults are starting points, not universal capacity recommendations.
How ADO.NET connection pooling works
When your application opens a SqlConnection, Microsoft.Data.SqlClient can supply a physical database connection from a matching pool. Disposing or closing the logical connection returns it for reuse when its configuration and transaction context permit. Your code should still create and dispose a connection for each unit of work; pooling is not a reason to hold one global connection open. Microsoft’s guidance is: “Open late, dispose early, and let the pool manage physical connections.” (Microsoft Learn: SQL Server connection pooling with Microsoft.Data.SqlClient.)
As an Amazon Associate I earn from qualifying purchases.
Which connection-string settings control the pool?
Microsoft documents these defaults for Microsoft.Data.SqlClient. They are provider defaults, not a tuning prescription for every application.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Option | Documented default | What it controls |
|---|---|---|
Pooling |
true |
Enables pooling. Set it to false only when you deliberately need to disable reuse. |
Min Pool Size |
0 |
Minimum physical connections retained by the pool. A positive value can keep database sessions open. |
Max Pool Size |
100 |
Maximum physical connections in one pool—not a process-wide or server-wide total. |
Connect Timeout |
15 seconds |
Time allowed to establish a connection or wait for an available pooled connection when the pool is full. |
Load Balance Timeout |
0 |
Age-based connection discarding; zero disables it. Connection Lifetime is an alias. |
These defaults are documented in Microsoft’s Microsoft.Data.SqlClient connection options. Increasing a limit or setting a nonzero minimum changes resource use; it does not by itself fix slow queries, leaked connections, or database capacity constraints.
#1 Best Overall
Keep connection configuration consistent
A connection is reused only by a pool matching its configuration. Exact connection-string text matters: changing keyword order can create a separate pool even when the effective settings are equivalent. Authentication identity, credentials or token handling, application name, and other settings can also affect pool selection. Transaction-enlisted connections may be held in transaction-specific subdivisions.
Use a canonical connection configuration across requests. Avoid placing per-request values in connection-string fields such as Application Name; variation can fragment reuse and multiply the connections your application may open. Microsoft documents the matching behavior in its connection-pooling overview.
Rank #2
Set provider options without keeping connections open
Pooling controls belong to the SqlClient connection configuration. A SqlConnectionStringBuilder helps set and validate options instead of assembling a string by concatenating values. Do not concatenate user-supplied values into a connection string; Microsoft describes the SqlConnection.ConnectionString property and builder approach.
For example, at the provider level, a builder can set pool options before creating a connection:
var builder = new SqlConnectionStringBuilder(existingConnectionString)
{
Pooling = true,
MinPoolSize = 0,
MaxPoolSize = 100,
ConnectTimeout = 15
};
using var connection = new SqlConnection(builder.ConnectionString);
await connection.OpenAsync();
// Run the database work, then dispose the connection promptly.This illustrates SqlClient options, not a prescribed ASP.NET Core configuration or secret-storage recipe. The Microsoft configuration reference available here includes older ASP.NET configuration examples, so its web.config pattern should not be treated as an ASP.NET Core setup guide: Connection strings and configuration files.
Prevent pool exhaustion before raising the limit
When a pool reaches its maximum, later connection opens wait for an available connection up to Connect Timeout. If none becomes available in time, connection acquisition fails with a timeout. The maximum applies per pool; the possible total also depends on how many distinct pools and application instances are running. Raising Max Pool Size without correcting long-held connections can shift the overload to SQL Server.
Rank #4
- Check disposal on every path. Inspect code that opens connections, data readers, and transactions. Ensure they are disposed even when an exception occurs, and that readers do not outlive the work that needs them.
- Look for multiple pools. Compare connection strings and authentication details used by different call paths. Differences such as keyword ordering or request-specific values can prevent reuse.
- Find work that holds connections too long. Review long-running queries and transactions, and reduce avoidable time between opening a connection and finishing database work.
- Estimate aggregate demand. Account for each pool and each service replica, then compare the possible connection total with database capacity.
- Change limits only with evidence. After the earlier checks, consider a measured adjustment if workload concurrency and database capacity support it.
For SqlClient-specific failure symptoms and investigation guidance, see Microsoft’s SqlClient Troubleshooting Guide.
Keep ambient transactions bounded
With Enlist=true, the default, connections opened within an ambient System.Transactions transaction automatically enlist. If a connection closes while that transaction is still active, it may remain in a transaction-specific subdivision until the transaction completes, making it unavailable to ordinary requests in the meantime. Keep ambient transactions short and complete them explicitly.
When to clear a pool
SqlClient can clear a pool automatically after certain recognized fatal errors, such as failover. ClearPool targets the pool associated with a connection configuration; ClearAllPools clears all SqlClient pools in the process or application domain. Clearing idle and checked-out connections leads to new physical logins as connections are needed. Use these APIs for a known configuration or credential boundary—not as periodic cleanup or a substitute for disposing connections. See Microsoft’s ADO.NET Provider for SQL Server pooling reference.
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.
