SSD Over-Provisioning: How Much Free Space Actually Improves Sustained Write Performance
An SSD that has filled up close to capacity writes noticeably slower under sustained load than the same drive with meaningful free space, and the reason is directly tied to how much room the controller has left to juggle blocks in the background.
An SSD writes data in pages but can only erase in much larger blocks, which means updating existing data requires the controller to first copy any still-valid pages out of a block, erase the whole block, then write the new data—a background process called garbage collection. The more free, unwritten space the controller has available, the more efficiently it can perform this shuffling without needing to do it under time pressure while a write is actively in progress, which is what causes sustained write speed to drop as a drive fills up.
Over-provisioning means deliberately leaving a portion of the drive's total capacity unpartitioned and therefore never written to by the operating system, giving the controller a permanent pool of guaranteed-free space to use for garbage collection and wear leveling regardless of how full the visible, usable partition gets. Enterprise and datacenter SSDs typically ship with 20 to 28 percent factory over-provisioning built in below the advertised capacity for exactly this reason; consumer drives ship with much less, often just enough for basic wear leveling, prioritizing advertised capacity over sustained write consistency.
Measured Impact on Sustained Write Speed
| Free Space Remaining | Typical Sustained Write Behavior |
|---|---|
| 50%+ free | Full-speed SLC cache and steady-state writes with minimal slowdown |
| 20–30% free | Noticeable but manageable slowdown once SLC cache is exhausted on long transfers |
| 10% or less free | Significant sustained write degradation; garbage collection struggles to keep pace under load |
| Near-full (under 5% free) | Worst-case sustained write speed, sometimes dropping to a fraction of rated sequential write |
The effect is more pronounced on drives that lean heavily on SLC caching to hit their advertised sequential write numbers, since once a sustained write exceeds the SLC cache size and the drive falls back to writing directly to its native TLC or QLC cells, having ample free space for garbage collection becomes the main thing standing between a graceful slowdown and a severe one.
How Much to Set Aside
- General desktop use (OS drive, games, casual use): keeping roughly 10 to 15 percent of the drive free through normal usage habits is usually sufficient; manual over-provisioning is not necessary for most people in this category.
- Sustained heavy write workloads (video editing scratch disks, large sustained file transfers, server-style continuous writes): deliberately partitioning to leave 15 to 25 percent unallocated meaningfully improves worst-case sustained write consistency, and is worth the capacity trade-off for this specific use case.
- QLC-based drives benefit more from over-provisioning than TLC drives at the same capacity, since QLC's narrower voltage margins per cell make garbage collection more computationally expensive, and QLC drives typically have a smaller dynamic SLC cache relative to their advertised capacity to begin with.
Over-provisioning is set up simply by partitioning less than the drive's full capacity and leaving the remainder unallocated rather than formatted; no special software or drive-specific tool is required for most consumer drives, though some manufacturer utilities offer a dedicated over-provisioning toggle that accomplishes the same result through their own interface.
Over-Provisioning on an Already-Full Drive
Setting up over-provisioning after a drive is already nearly full requires actually freeing that space first, not just resizing a partition around existing data, since the controller needs those blocks to be genuinely empty (properly TRIMmed) to use them for garbage collection, not merely unlisted in the file system while still holding stale data the controller doesn't know is safe to erase. Shrinking a partition without first deleting data and issuing a TRIM command on the freed space can leave the controller unaware that the newly unallocated area is actually available, undermining much of the intended benefit until a full TRIM pass runs.
The straightforward approach is to back up data, securely wipe or fully re-format the drive, then create the partition at the reduced size from a clean state, ensuring the unallocated space was never written to in the first place. For drives already deployed in an active system where a full wipe is inconvenient, running a manual TRIM pass on the freed space after shrinking a partition (most operating systems provide a way to force this) is a reasonable substitute that achieves a similar result without requiring a full data migration.