How can developers identify and resolve database connection pool exhaustion in an ASP.NET Core application?

Connection pool exhaustion occurs when an application has more concurrent database connections in use than the available pool or database capacity can support. The important point is that increasing the pool size is not automatically the solution. If connections are being held too long because of slow queries, uncommitted transactions, blocked database calls or incorrect connection lifetime management, increasing the pool can simply postpone the failure.

ADO.NET uses connection pooling to reuse database connections, while EF Core's DbContext pooling is a separate concept. Microsoft explicitly distinguishes database connection pooling from EF Core DbContext pooling.

A typical symptom may look like:

ASP.NET Core Requests
        |
        +---- Request A ---- DB connection
        |
        +---- Request B ---- DB connection
        |
        +---- Request C ---- DB connection
        |
        +---- Request D ---- waits
        |
        +---- Request E ---- waits
                         |
                         v
                Connection Pool Exhausted

Investigation approach

Start by determining whether the application is opening too many connections or holding connections for too long.

Check:

1. Database connection pool configuration.
2. Application request concurrency.
3. Long-running SQL queries.
4. Blocking and deadlocks.
5. Transactions that remain open too long.
6. Connections that are not disposed correctly.
7. Synchronous database calls blocking application threads.
8. Excessive parallel database operations.
9. Database-side connection limits.
10. Application telemetry and database metrics.

ASP.NET Core and EF Core guidance recommends asynchronous data access, retrieving only the required data and minimising unnecessary database round trips. EF Core also provides metrics that can help identify database-related application behaviour.

A common anti-pattern

public async Task<Customer> GetCustomer()
{
    var connection = new SqlConnection(connectionString);

    await connection.OpenAsync();

    // Long-running processing...

    return customer;
}

The problem is not merely opening the connection. The critical question is how long the connection remains occupied.

Prefer keeping the database connection lifetime close to the actual database operation and avoid holding a connection while performing unrelated processing.

Enterprise diagnosis

High API Latency
       |
       v
Check DB Wait Time
       |
       +---- High Query Time
       |       |
       |       v
       |   Tune Query / Index
       |
       +---- High Connection Usage
               |
               v
       Check Connection Lifetime
               |
               +---- Long Transactions
               +---- Leaked Connections
               +---- Excessive Concurrency
               +---- Pool Configuration
               +---- DB Connection Limits

Do not confuse:

Connection Pooling

with:

DbContext Pooling

They solve different problems. Database connection pooling is handled by the underlying provider, while EF Core DbContext pooling reuses context instances.

For students: understand DbContext, connection lifetime, async/await and basic connection pooling.
For professionals: investigate pool saturation alongside SQL performance, transaction duration, concurrency, database limits and application telemetry before changing pool-size settings.