ADO.NET Connection Pooling: Effects of Changing Max Pool Size Defaults Across .NET Versions

Goal: Determine whether adjusting Max Pool Size or enforcing stricter disposal resolves intermittent pool exhaustion when upgrading from .NET Framework to .NET 6.

In .NET Framework applications, the default Max Pool Size is 100 and pooling behavior is tightly coupled to the legacy SqlClient provider. When migrating to .NET 6, the underlying Data Provider may adjust pool partitioning rules or timeout handling, creating a compatibility boundary where the same connection string yields different pool limits under load.

Constraints include the inability to observe pool metrics without enabling performance counters, the risk that increasing Max Pool Size shifts pressure to the database server, and the uncertainty that connection leaks manifest only under sustained concurrency.

• Does the default Max Pool Size remain 100 in .NET 6's SqlClient, or has it changed?
• How does a variation in connection string whitespace affect pool partitioning between the two runtime versions?
• What is the threshold at which pool exhaustion shifts from client‑side queuing to server‑side session limits when scaling Max Pool Size across multiple instances?