Introduction

Seeing many SQL Server sessions in sleeping status can look like a connection leak, but in EF Core that is often normal connection pooling behavior. The real question is not whether sleeping connections exist, but whether they are being returned to the pool properly and whether the application is exhausting the pool over time.

Why Sleeping Connections Appear

EF Core sits on top of an ADO.NET provider such as Microsoft.Data.SqlClient. That lower layer uses connection pooling by default. When EF Core finishes using a connection, the connection is usually closed logically and returned to the pool rather than physically destroyed.

SQL Server can still show that pooled connection as sleeping. That does not automatically mean EF Core forgot to dispose it.

In other words:

• sleeping can be normal
• growing counts without reuse can indicate a lifetime problem
• timeout exceptions are a stronger leak signal than the presence of sleeping sessions alone

Use Short-Lived DbContext Instances

The safest pattern is to keep DbContext short-lived and dispose it promptly.

1await using var context = new AppDbContext(options);
2var users = await context.Users
3    .Where(u => u.IsActive)
4    .ToListAsync();

In ASP.NET Core, the standard scoped lifetime usually handles this correctly per request when DbContext is registered through dependency injection.

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

That setup is usually enough. You do not need to open and close the connection manually for every normal query.

What Actually Causes Connection Problems

True connection-management issues usually come from one of these patterns:

• long-lived DbContext instances shared too broadly
• manually opening a connection and never closing it
• unfinished streaming operations that keep the reader open
• transactions that are not disposed correctly
• sync-over-async or blocked threads causing request pileups

Example of explicit connection control that must be balanced carefully:

1await using var context = new AppDbContext(options);
2await context.Database.OpenConnectionAsync();
3try
4{
5    var count = await context.Users.CountAsync();
6    Console.WriteLine(count);
7}
8finally
9{
10    await context.Database.CloseConnectionAsync();
11}

If you call OpenConnectionAsync, then you own the responsibility to close it.

How to Tell Pooling From a Leak

A pooled application may show dozens of sleeping sessions and still be perfectly healthy. What matters is whether the count stabilizes and whether requests continue to complete normally.

Warning signs include:

• the number of sleeping sessions keeps climbing without leveling off
• requests start timing out waiting for a connection
• the process creates more contexts than expected under load
• explicit connection opens outnumber closes in logs or traces

That is why monitoring exception rates and pool exhaustion is more useful than reacting to the word sleeping alone.

Practical Debugging Steps

Start with lifetime inspection:

1. confirm DbContext is scoped, not singleton
2. search for manual OpenConnection calls
3. check for IAsyncEnumerable or data readers that are not fully consumed
4. look for transactions or contexts that live across background jobs unintentionally
5. enable EF Core and provider logging during a load test

If you need extra throughput, connection-pool tuning may help, but it should come after fixing lifetime bugs rather than as a substitute for them.

Common Pitfalls

The biggest mistake is assuming every sleeping SQL connection is a leak. With connection pooling, sleeping sessions are expected.

Another issue is holding onto DbContext instances for too long. EF Core is designed around short units of work, not around application-wide contexts.

A third problem is manually opening connections for ordinary queries when EF Core would manage that safely on its own.

Summary

• Sleeping SQL connections are often pooled idle connections, not leaks.
• The real danger signal is pool exhaustion or steadily growing unreleased sessions.
• Keep DbContext short-lived and dispose it promptly.
• If you open a connection manually, close it manually.
• Diagnose lifetime and transaction issues before tuning the connection pool.