Timeout expired obtaining a connection from the pool in PowerShell System.Data.SqlClient scripts
0 reputation · 01 Feb 2026, 08:22 UTC
0 reputation · 01 Feb 2026, 08:22 UTC
In Windows PowerShell 5.1 and PowerShell 7+ sessions using System.Data.SqlClient, scripts that create SqlConnection objects without explicit disposal can intermittently throw a SqlException with the message: "Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached." The underlying .NET connection pool does not automatically reclaim connections when PowerShell variables leave scope; they remain pooled until explicitly closed or the process ends.
An unresolved design decision in PowerShell is whether it should automatically call Dispose on .NET objects that implement IDisposable when they go out of scope, which would prevent such leaks but is not currently implemented. Because PowerShell sessions are often long-running, this leaves module authors without language-level guarantees for deterministic cleanup.
When building reusable functions that open SqlConnection objects, what is the most reliable pattern for ensuring connections return to the pool without relying on garbage collection? Should authors explicitly invoke Close or Dispose in every code path, or is there a documented alternative that addresses the unresolved automatic-disposal question? How can long-running scripts avoid intermittent pool exhaustion when the language does not enforce scope-based disposal?
A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.