What’s the issue?
Tempdb is the SQL Server system database used for sorts, hash joins, temporary tables, table variables, version store activity, and many internal operations. Because tempdb is shared by every database and every session on the instance, its placement and storage performance affect the entire workload.By default, when SQL Server is installed without customizing the storage configuration, tempdb files are placed under the SQL Server installation directory on the C drive. If the team does not move tempdb during initial setup or shortly after, the files remain on C indefinitely.
This finding identifies instances where one or more tempdb files (data or log) are located on the C drive even though additional drives are available on the server. The condition is likely the result of accepting the installation defaults without customization.
Why is this a problem?
Placing tempdb on the C drive consumes space on the operating system volume, which is sized for Windows and SQL Server binaries rather than for high-volume database activity. Tempdb growth, particularly during heavy workloads or unexpected spikes, can fill the C drive and cause Windows itself to become unstable, paging to fail, and all other kinds of bad.Tempdb on C also competes with the operating system for I/O on the same physical drive. Modern best practice is to place tempdb on dedicated, fast storage where the I/O patterns of tempdb (heavy random reads and writes, sustained throughput) do not interfere with operating system activities such as logging, paging, and binary access. The C drive is rarely sized or configured for this kind of sustained database I/O.
Performance is also affected by sharing storage with other workloads on C. The operating system, antivirus tools, monitoring agents, and any other processes running on the host all use the C drive, producing contention that elevates tempdb latency and reduces overall instance throughput. A dedicated tempdb drive avoids this contention entirely.
This condition often exists unnoticed because it does not produce immediate, obvious symptoms during light workloads. The instance functions normally, queries return results, and the issue surfaces only during heavier activity or when tempdb growth begins to consume meaningful space on C. By that point, moving tempdb requires planning and a service restart.
What should you do about this?
Move tempdb files to the appropriate dedicated drive. The change is recorded immediately, but tempdb file relocations require a SQL Server service restart to take effect, since tempdb is recreated at each service start.When possible, place tempdb on dedicated, fast storage sized for the actual workload, ideally SSD or NVMe with no other databases or operating system files sharing the volume. Pre-size the tempdb data and log files to fill most of the drive at startup so autogrowth is rare during normal operation. There may be considerations with regard to monitoring software when doing this.
Update the instance-level default data path so future databases are not created on the C drive by mistake, and add tempdb placement to your standard server build checklist so new installations follow the standard from the start.