Monitor the connection pool in the database driver, not in EF Core. For SQL Server with Microsoft.Data.SqlClient, attach dotnet-counters to the ASP.NET Core process and inspect SqlClient EventCounters. For PostgreSQL with Npgsql, inspect the provider’s .NET metrics, including connections by state and pool identity. EF Core metrics add useful context about queries and failures, but they do not report driver-pool occupancy.
Start with the provider and its version
Pool metrics and their names depend on the driver. First identify the provider package and version deployed by the application, then check its documented runtime requirements and metric names. The commands below attach to an already running ASP.NET Core process; replace the process-ID placeholder with that process’s ID.
As an Amazon Associate I earn from qualifying purchases.
- Identify the provider. Use SqlClient metrics for SQL Server applications using Microsoft.Data.SqlClient, or Npgsql metrics for PostgreSQL applications using Npgsql.
- Find the process ID. Identify the running ASP.NET Core process that you want to observe.
- Run the provider-specific monitor. Keep the measurement window and workload in mind when comparing readings.
- Correlate the readings. Compare pool signals with request rates, database latency, exceptions, and EF Core activity.
- Check pool configuration. Interpret counts against the deployed provider’s configured limits, rather than assuming a universal pool-size threshold.
Monitor Microsoft.Data.SqlClient pools
For Microsoft.Data.SqlClient, use its EventSource with dotnet-counters:
Recommended Free Tools
dotnet-counters monitor --counters Microsoft.Data.SqlClient.EventSource -p <process-id> --refresh-interval 3SqlClient also documents selecting particular counters, such as hard-connects and hard-disconnects. EventCounters require Microsoft.Data.SqlClient 3.0.0 or later and .NET Core 3.1 or .NET Standard 2.1 or later; use the provider’s framework-specific guidance for other configurations. SqlClient distinguishes these modern cross-platform EventCounters from .NET Framework performance counters. See the Microsoft.Data.SqlClient EventCounters documentation.
Read the counters together
number-of-active-connectionscounts connections currently in use;number-of-free-connectionscounts connections ready in pools.number-of-pooled-connectionsreports connections managed by the pooling infrastructure. It is not the same as the number currently in use.number-of-active-connection-poolsandnumber-of-active-connection-pool-groupscan reveal pool proliferation. Pool groups correspond to unique connection strings; Windows integrated authentication can create separate pools per Windows identity within a group.hard-connectsandhard-disconnectstrack physical connections opened to and disconnected from database servers.soft-connectsandsoft-disconnectstrack connections retrieved from and returned to a pool.number-of-stasis-connectionscounts connections waiting for an action to complete and unavailable to the application.number-of-reclaimed-connectionscounts connections reclaimed through garbage collection because the application did not call Close or Dispose. Repeated growth is a reason to inspect disposal paths.
High active use with few free connections, especially near configured capacity, can indicate pressure. Rising pool counts can point to many distinct connection strings or identities. Frequent hard connections relative to pooled reuse can indicate that physical connections are being established often. These patterns are diagnostic clues, not proof of a single cause.
Monitor Npgsql pools
For Npgsql, monitor its .NET meter with dotnet-counters:
dotnet-counters monitor --counters Npgsql -p <PID>Review connection counts split by idle and used, the maximum connection count, and the pool or data-source identity. Use the identity dimension to distinguish multiple databases or data sources. By default, the pool name is the connection string; an Npgsql data source can instead be given a more stable explicit name. Npgsql pools connections by default, and disposing an Npgsql connection returns it to the internal pool. See the Npgsql metrics documentation and connection-string parameters.
Npgsql documents a maximum pool size of 100 since version 3.1, but that is a provider-specific default, not a recommended limit for every application. Verify the deployed version and configuration. Npgsql 10.0 renamed metrics to align with OpenTelemetry, so update dashboard queries and alerts to match the version in use. See the Npgsql 10.0 release notes.
Rank #3
Use EF Core metrics as supporting signals
EF Core metrics describe EF-level activity, not the driver’s pool inventory. EF Core 9.0 introduced System.Diagnostics.Metrics reporting; its Microsoft.EntityFrameworkCore meter and legacy counters can help track activity and failures. Metrics such as active_dbcontexts, query activity, saves, and failures do not tell you how many driver connections are idle, used, or available. See the EF Core metrics documentation.
Connection pooling is implemented by the database driver and is separate from EF Core DbContext pooling. EF Core generally opens a connection close to an operation and closes it afterward so the driver can return it to its pool. Turning on context pooling therefore does not expose or measure connection-pool occupancy. See EF Core’s connection-pooling guidance.
Choose the signal that answers the question
| Monitoring approach | Direct pool-state visibility | Pool or data-source dimension | Physical connection versus reuse signal | Version and fit considerations |
|---|---|---|---|---|
| Microsoft.Data.SqlClient EventCounters | Active, free, pooled, and stasis connection counts | Active pools and pool groups; grouping is affected by connection strings and, for integrated authentication, Windows identities | Hard and soft connects and disconnects | EventCounters require Microsoft.Data.SqlClient 3.0.0 or later and .NET Core 3.1 or .NET Standard 2.1 or later; check provider guidance for other configurations. |
| Npgsql .NET metrics | Used and idle connection counts plus maximum connection count | Pool or data-source identity | These cited metrics describe pool state; they do not provide the SqlClient hard/soft counter names | Metric names changed in Npgsql 10.0; align dashboards and alerts with the deployed version. |
| EF Core metrics | No direct driver-pool inventory | EF Core application activity, rather than driver pool identity | Query, save, and failure activity can be correlated with provider signals | EF Core 9.0 introduced System.Diagnostics.Metrics reporting; these metrics do not replace provider instrumentation. |
Interpret trends without guessing at a universal limit
Compare active or used connections with free or idle connections and the configured maximum for the specific provider and data source. Track those values over time under a known workload, alongside request volume, database latency, and errors. A high active count alone does not establish a pool problem: slow queries, server-side connection failures, or a workload increase can produce different symptoms that need to be separated with correlated signals. Likewise, a spike in pool count or hard connections is a lead to investigate, not a diagnosis.
Quick Recap
- If active or used connections approach the configured maximum while free or idle capacity stays low, investigate connection hold times and workload behavior.
- If SqlClient hard-connect activity is high compared with soft reuse, inspect whether the application is repeatedly establishing physical connections.
- If pool counts grow, examine connection-string variation and, for SqlClient with integrated authentication, identity-related pool separation.
- If reclaimed SqlClient connections repeatedly rise, review whether every opened connection is closed or disposed on all code paths.
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.
