dbatools 2.8.4 allows `Set-DbaTempDbConfig` to force a reduction in TempDB data files. The capability is useful when an oversized configuration must be corrected, but its existence should not normalize shrink as recurring maintenance. TempDB is a shared working area for sorting, version stores, spills, temporary objects, and internal engine activity; reclaiming space while it is busy can create blocking and unpredictable duration.
Why it matters in production
The first question is why the files grew. A one-time incident, index operation, version-store backlog, poor query plan, or deliberately pre-sized workload creates a different answer from permanent over-allocation. Capture file use, free space, autogrowth history, version-store pressure, active requests, and storage capacity. Shrinking without addressing the cause merely converts stable allocation into repeated growth and more operational noise.
A controlled decision defines the target file count and size, expected future workload, growth increment, maintenance window, and abort criteria. Compare online reduction with a planned SQL Server restart or configuration change where that is safer. Test on a representative instance and monitor blocking, waits, I/O, log behavior, and application latency while the operation runs.
Automation should present evidence before accepting `-Force`. Record current and proposed values, active use, approval, result, and post-change growth. Do not let a generic configuration job shrink files simply because desired state declares a smaller number. Capacity policy must distinguish allocated space from waste and emergency correction from normal steady state.
Practical takeaway
The practical takeaway is to keep TempDB shrink exceptional. Diagnose growth, choose a defensible target, schedule the operation with workload awareness, and verify behavior afterward. The best TempDB maintenance usually prevents avoidable growth or sizes files correctly; it does not repeatedly return space that the workload will request again.