Setup's quiet default buries every database file inside the C drive's Program Files. On a real server that is the first thing to change — here is where each file type belongs and why.
A SQL Server database is not one file. Every database has data files (.mdf/.ndf) holding the tables, and a transaction log (.ldf) recording every change in order — plus shared system files and TempDB, the engine's scratch workspace. Setup's Data Directories page decides where all of these land for every future database. Spend two minutes there, or spend a weekend later moving files on a live server.
Data files are read and written in a scattered, random pattern as queries jump between pages. A transaction log is the opposite: a strict, fast, sequential stream — every committed change must be safely written to the log before SQL Server calls it done. When both share one busy disk, random data traffic slows the log writes, and slow log writes slow every transaction on the server. Separating them onto different volumes (best: different physical drives or SSDs) removes that fight. On modern single-SSD machines the gap shrinks, but the separation still buys you clarity and room to grow.
TempDB is used by every database on the instance for temporary tables, sorting, version-store rows and intermediate results. A heavy report can make it grow fast, and when TempDB shares the system drive, TempDB growth can fill C: and take Windows down with it — a failure that has nothing to do with your actual data. Put TempDB on a fast, roomy volume, accept setup's suggestion of multiple data files matched to your core count (up to eight, all the same size), and set a sensible fixed growth increment so files grow in planned steps rather than tiny increments all day.
Setup asks for a default backup directory, and whatever you choose, understand this: a backup file sitting on the same physical drive as the database is not protection — the drive failure takes both copies together. Point the default at a separate volume if you have one, and then arrange for those files to be copied to another machine or external storage on a schedule. Our backup guide builds that routine; this guide's only demand is that the directory choice happens consciously, not by default.
The Data Directories page sets four paths: the data root, user database data files, user database log files, and backups. Change them now and every database created later lands correctly with zero effort. Databases created before the change keep their old locations — the setting is a default for the future, not a mover of the past. Also worth deciding now: names and growth. Files that auto-grow by 1 MB at a time fragment and stall; when you create important databases, set growth in sensible megabyte steps instead of the tiny default.
D:\SQLDataE:\SQLLogsIf a database already lives in the wrong place, the safe move is documented and calm: note the current paths from SELECT name, physical_name FROM sys.master_files;, set the database offline, move the files in Explorer to the new volume, alter the database to point at the new paths, and bring it online. Never drag files of a running database, and never just delete a stray .ldf hoping SQL Server will cope — the engine expects its files exactly where its catalog says. With setup defaults set correctly from day one, you will rarely need this procedure at all.
Watch the video's install and check the Data Directories and TempDB tabs — two minutes on that screen arranges storage for the life of the server.
▶️ Watch Full VideoNot pointless, just less about speed. Separate folders still keep the system drive from being filled by database growth, make backups and migrations easier to reason about, and let you add a second drive later and move only the logs. On one SSD the performance argument fades; the housekeeping argument stays.
There is no universal number — watch how large TempDB grows during your busiest week and pre-size the files a little above that, all equal in size, with a fixed growth step (for example 512 MB) instead of percentage growth. Equal sizes matter because TempDB fills its files proportionally.
Yes, but it is a different, more delicate procedure involving startup parameters, and tempdb is the exception that simply gets recreated at the path configured in sys.master_files on restart. Leave system databases alone unless you have a concrete reason — the wins in this guide come from user data, logs and TempDB placement.