Investigate an endpoint that times out under concurrency even though individual SQL queries are fast.

The endpoint manually opens a database connection and returns early on one validation branch without closing it. In an isolated test database, configure a small pool, repeat that branch, and show a corrected await using scope. Do not stress the developer or production database.

Query duration remains low, but connection acquisition time and timeout count rise until the pool is exhausted. Fixing disposal restores steady active/idle connection behavior.

• Use a disposable database with a deliberately small test pool.
• Bound concurrency and test duration.
• Measure acquisition separately from query execution.
• Restore service health before deeper production diagnosis.

I separate evidence: fast database commands plus slow connection acquisition points to pool pressure rather than query execution. The code fix makes ownership explicit with await using, including early returns and exceptions.

public static async Task<Customer?> LoadCustomerAsync(
    DbDataSource dataSource,
    Guid customerId,
    CancellationToken cancellationToken)
{
    await using var connection = await dataSource.OpenConnectionAsync(cancellationToken);
    await using var command = connection.CreateCommand();
    command.CommandText =
        "SELECT customer_id, display_name " +
        "FROM customers WHERE customer_id = @customer_id";

    var parameter = command.CreateParameter();
    parameter.ParameterName = "@customer_id";
    parameter.Value = customerId;
    command.Parameters.Add(parameter);

    await using var reader = await command.ExecuteReaderAsync(cancellationToken);
    if (!await reader.ReadAsync(cancellationToken))
        return null;

    return new Customer(reader.GetGuid(0), reader.GetString(1));
}

The production evidence chain is request concurrency, connection acquisition duration, active/idle pool counts, database sessions, and recent code changes. A focused isolated load test can prove the fix; increasing pool size alone only delays exhaustion.

• Early return before command execution.
• An exception occurs while reading.
• Cancellation interrupts connection acquisition.
• One downstream dependency holds transactions open.

• Use a low pool maximum in a disposable test environment.
• Assert all tasks finish after the fix.
• Observe pool metrics returning to baseline.
• Keep the reproduction bounded and cancellable.

• Blaming slow SQL when acquisition is slow.
• Increasing pool size without fixing ownership.
• Opening connections without deterministic disposal.
• Load-testing a shared local or production database.