What is latency variance between NAND SLC and TLC under sustained write?
In the world of high-performance database storage, "Average Latency" is a marketing number. For a DBA, the number that actually matters is Latency Variance (or jitter).
When a database is under a sustained write load—such as a massive Data Pump import or a heavy Redo Log sync—the physical difference between SLC (Single-Level Cell) and TLC (Triple-Level Cell) NAND becomes a performance chasm.
To understand the variance, you have to look at how a bit is actually stored:
SLC: Stores 1 bit per cell. The controller only needs to distinguish between two voltage states (0 or 1). It’s a "binary" toggle.
TLC: Stores 3 bits per cell. The controller must precisely manage 8 different voltage levels within that same tiny cell.
The Variance Trigger: As a drive heats up or fills up during a sustained write, the "precision" required to hit one of those 8 voltage levels in TLC becomes significantly harder. If the first attempt fails, the controller must retry, causing a latency spike.
Most modern enterprise TLC drives use a "Pseudo-SLC Cache." They treat a portion of their TLC capacity as SLC to give you fast initial bursts.
The SLC Experience: Latency is a flat line. Whether you write 1GB or 1TB, the "binary" nature of the cell allows for consistent $20\mu\text{s} - 30\mu\text{s}$ writes.
The TLC "Cliff": Once the SLC cache is full, the drive must perform "folding"—moving data from the fast SLC cache into the slow TLC blocks while simultaneously accepting new writes.
The Result: Latency jumps from $30\mu\text{s}$ to $200\mu\text{s} - 1,000\mu\text{s}$. This isn't just a "slowdown"; it’s a massive increase in Variance.
Under a sustained, heavy database workload, the "tail latency" (the worst-case scenarios) looks very different:
| Metric | SLC (Enterprise) | TLC (Enterprise/Data Center) |
| Typical Write Latency | $25\mu\text{s}$ | $40\mu\text{s} - 80\mu\text{s}$ |
| Sustained $p99$ Latency | $35\mu\text{s}$ (Rock Solid) | $300\mu\text{s} - 600\mu\text{s}$ (Spiky) |
| $p99.99$ (The Outliers) | $< 100\mu\text{s}$ | $2,000\mu\text{s} - 5,000\mu\text{s}$ |
| Reason for Variance | Physics (Simple) | Garbage Collection + Folding |
In an Oracle or SQL Server environment, the Log Writer is extremely sensitive to these spikes.
With SLC: Every COMMIT takes roughly the same amount of time. Your application performance is predictable.
With TLC: 99% of your commits are fast, but 1% take 100x longer. This causes "convoy effects," where hundreds of sessions queue up behind one slow log write. This manifests as "unexplained" application hiccups and $p99$ response time degradation.
You don't need SLC for everything—it's too expensive. The optimized database strategy is:
Redo Logs / WAL: Use SLC (or high-end Intel Optane/PMEM). The low variance ensures your commits never "hiccup."
Temp / Undo Tablespaces: Use High-End MLC or TLC. These can handle some jitter without killing the user experience.
Data Files: TLC is perfectly fine here. Most database reads are served from the Buffer Cache anyway, and background writes (DBWR) are asynchronous and less sensitive to millisecond-level jitter.
If your database "feels" fast most of the time but suffers from random, periodic slowdowns during heavy loads, you are likely hitting the TLC Latency Wall. SLC provides the "determinism" that enterprise databases crave. In the world of storage, speed is great, but consistency is king.