TLC (Triple-Level Cell) and QLC (Quad-Level Cell) are the two NAND flash types behind most enterprise SSDs today. TLC stores 3 bits per cell, QLC stores 4. The extra bit gives QLC roughly a third more density per wafer, and typically twice the density per SSD, at the cost of random write speed and total write endurance. That tradeoff hasn’t changed. What’s changed is that the technology has advanced significantly, and QLC’s practical downsides are now small enough that the decision deserves more than a one-line answer.
NAND flash contract prices are projected to climb another 55-60% quarter over quarter into 2026, on top of increases that have already topped 300% since 2025. At that pricing, “just buy TLC, it’s the better NAND” stops being a simple recommendation and starts being a real budget decision.
Here’s how the two actually compare, why QLC performs better than the spec sheet suggests, and how OpenZFS’s write path changes the calculation on TrueNAS specifically.
NAND Flash: A Quick Refresher
Flash memory stores data as voltage levels in floating-gate transistors, not as magnetic states on a spinning platter. The first SSDs used Single-Level Cell (SLC) NAND: one bit per cell, two possible voltage states, fast and durable but expensive per gigabyte. Multi-Level Cell (MLC) doubled density to 2 bits per cell. TLC and QLC pushed that further, to 3 and 4 bits per cell, by packing 8 and 16 distinct voltage states into the same physical cell.
The more bits in a single cell, the more densely packed the voltage peaks are.
Voltage states by NAND type: SLC/MLC/TLC/QLC voltage curve comparison.
More voltage states per cell means more density, and it also means more work. The controller has to write and read smaller, more precise voltage differences, and error correction has to do more to tell those states apart reliably. The time required to read, write, and erase each flash cell increases significantly as the number of layers increases, with both performance and endurance declining as bit density rises. It’s a direct consequence of how many states a single cell has to represent, not an arbitrary manufacturing choice.
Practically: TLC gives you better sustained write speed, lower and more predictable latency, and meaningfully more program/erase cycles before cells wear out. QLC gives you more capacity per dollar and per rack unit, at the cost of all three.
Pseudo-SLC (pSLC) Caching Explained
Pseudo-SLC caching (pSLC) is what lets a TLC or QLC drive briefly run its cells in 1-bit mode, so incoming writes land at SLC-like speed before they’re moved to their native multi-bit state in the background. It’s the reason a QLC drive’s marketing benchmark can look almost as fast as a TLC drive’s, even though the underlying NAND is slower.
The mechanism is straightforward. Incoming writes hit a reserved pool of cells running in single-bit mode, where they’re fast to program because the controller only has to distinguish two voltage states instead of eight or sixteen. Once the write is acknowledged, the drive’s controller “folds” that data back into native TLC or QLC density as a background process, freeing up pSLC capacity for the next burst.
pSLC cache lets these drives write fast, but causes write amplification as part of the “folding” process.
pSLC caching mechanics: reserved pSLC pool writing fast/coarse vs. fold-back into native fine-grained TLC/QLC cells.
This is genuinely useful for the workload it’s built for: short, bursty writes with idle time in between to let the fold-back catch up. It’s less useful once a workload doesn’t give the drive that idle time. Two limits matter for planning:
The pSLC cache area isn’t free. Reserving cells for single-bit mode means borrowing from the drive’s available NAND capacity, and that pool typically shrinks as the drive fills up, which is exactly when you’d want more of it. Some drives will allow the entire drive to be written in pSLC mode, while others have a lower fixed capacity.
If the writes come in faster than the drive can fold into its TLC or QLC cells, then the pSLC cache can run out under sustained load. Once the pSLC pool is exhausted, writes drop to the drive’s native TLC or QLC speed, and the fold-back process itself competes with incoming writes for the same NAND die. On QLC, that drop-off is more pronounced, because native QLC write speed is further from the cached speed than TLC’s is.
That second point is the one that actually matters for procurement: a benchmark run for thirty seconds on an empty drive tells you almost nothing about how that drive performs after four hours of continuous writes. Sustained-write workloads see a real gap between TLC and QLC. Bursty or read-heavy workloads generally don’t.
How OpenZFS Transaction Groups Affect pSLC
OpenZFS doesn’t write to disk the moment an application requests it. Writes accumulate in memory as a transaction group (TXG), batched together over a short interval (no longer than five seconds by default), and then committed to the pool as one larger, more sequential operation instead of many small, scattered ones.
Batching up small, disorganized writes into larger blocks allows TLC and QLC NAND to be programmed more efficiently, improving performance while preserving cell endurance.
That batching matters directly for pSLC-cache economics, on both TLC and QLC. A stream of small, random writes hitting a drive constantly consumes and refills the pSLC pool, keeps the fold-back process running nonstop, and drives write amplification up as the controller shuffles data between cache and native cells more often than the actual data volume requires. Fewer, larger, more sequential commits do the opposite: they let the drive absorb a batch, fold it back during the gap before the next TXG commits, and avoid the worst case where cache exhaustion and background fold-back compete for the same NAND die at the same time. A workload with a bursty nature can even be programmed directly to the slower TLC or QLC NAND, with the pSLC cache left free to handle any unexpected writes that need to be quickly handled.
The effect is more pronounced on QLC, because QLC has a smaller cache-to-capacity ratio and the steeper falloff once that cache is gone – but batching writes doesn’t turn QLC into TLC. It does mean the drive spends more time inside the range where pSLC caching is doing its job, and less time in the degraded native-speed state that shows up in real-world benchmarks after the marketing numbers stop applying.
The claim that “our SSD has a 100GB pSLC cache and ZFS only holds 4GB of dirty data” is comparing the wrong things. ZFS’s dirty data limit governs how much unwritten data queues in system memory before the write throttle engages. That’s a completely different layer from the pSLC cache living inside the drive’s own controller. Getting the most out of either NAND type on TrueNAS depends on both working together: OpenZFS shaping the write pattern before it ever reaches the drive, and the drive’s own NAND allocation and pSLC cache absorbing what arrives.
So Which One Should You Buy?
Now that TrueNAS ships both, the answer depends on the write pattern, not on a NAND type being categorically better.
Sustained, write-heavy workloads (databases with constant transaction logging, VDI boot storms, anything that keeps writes coming with no idle gap) still favor TLC. That’s where QLC’s native write speed and lower endurance show up as real, measurable degradation, and it’s why TrueNAS F-Series all-NVMe systems are built around it; however, for large SSDs above 100TB, QLC is the only game in town.
Capacity-bound, read-heavy, or bursty workloads (media archives, backup targets, analytics datasets that are written once and read often) are where QLC’s density and cost per terabyte win outright, and where OpenZFS’s write batching keeps the drive inside its pSLC comfort zone most of the time. TrueNAS supports both TLC and QLC in the same all-flash or hybrid chassis, so that choice doesn’t have to be made once and locked in for the system’s life.
And if the honest answer is “we don’t know yet which way our workload will trend, and we don’t want to guess at 2026 flash prices,” that’s a real third option. The TrueNAS V160 was built specifically to let you run either TLC or QLC in an all-flash, hybrid, or any mix in between, and adjust that mix later without re-architecting.
How about Hybrid Storage?
In the current market with NAND prices pushing budgets to the brink, it’s no surprise that hybrid storage solutions are making a comeback in popularity – and TrueNAS was designed with hybrid storage in mind from the beginning. With an intelligent Adaptive Replacement Cache (ARC) system, and leveraging SSD acceleration for both read (L2ARC) and write (SLOG) workloads, a TrueNAS system with hybrid storage can deliver flash-like performance where your data really requires it, while still leveraging spinning-disk economics to give you the capacity you need.
Flash pricing isn’t going back to 2024 levels this year. Talk to a TrueNAS solutions engineer about which NAND type, storage layout, and system design actually fits your workload. We’ll size it to what you’re running, not to whichever spec sheet number looks best this quarter.
FAQ
What’s the actual difference between TLC and QLC NAND flash?
TLC stores 3 bits per cell and QLC stores 4. The extra bit gives QLC more density per SSD and lower cost per terabyte, at the cost of slower native write speed, higher latency under sustained load, and fewer program/erase cycles before cells wear out. QLC is recommended for higher capacity, lower performance or read-intensive workloads.
Does pseudo-SLC caching make QLC as fast as TLC?
Only for bursts. pSLC caching lets QLC write at SLC-like speed until its reserved cache fills, then performance drops to QLC’s native speed while the drive folds cached data back in the background. Under sustained random write pressure, the gap with TLC reappears.
Why does OpenZFS matter to this decision?
OpenZFS batches writes into transaction groups before they reach the drive, turning many small random writes into fewer, larger, sequential ones. That reduces how often a drive’s pSLC cache gets exhausted and refilled, which benefits QLC’s practical performance more than TLC’s, since QLC has less cache headroom to begin with.