Large QLC Drives: Capacity Is Cheap, Writes Are Not

A large QLC drive wins the only comparison most quotations contain: money divided by capacity. It can win that line by a wide margin and still be the more expensive drive to own, because the comparison measures the part of the product the buyer already understands and ignores the part the drive will spend its life doing. The gap sits in the datasheet, in a section the purchase order rarely quotes.

The line item that wins the page

A large QLC drive wins the line-item comparison for a reason that has nothing to do with writes. Density is the product. Four bits per cell pack more capacity into the same package than any other NAND class in volume production, so one drive can replace several smaller ones and take their controllers, cables, slots, power draw and cooling with it. On a bill of materials it reads as savings, and the savings are real — at purchase and every month after, in the power and space the drive does not consume.

Density also fixes the write behavior. QLC cells endure fewer program and erase cycles than TLC or SLC cells, and they take longer to program. Those are not defects or firmware quirks; they are the same physical trade that produced the capacity. A comparison that counts only capacity counts the benefit and leaves the cost outside the arithmetic. A drive such as the Solidigm SBFPF2BV0P12001 is the shape of part this argument concerns.

Two cost pools, one invoice

The invoice records what it costs to buy the capacity; the deployment records what it costs to write to it, and the second pool arrives without a line item. The second pool is paid in capacity held back from the application, in write shaping and monitoring nobody budgeted for, in latency while the drive folds data, and in replacements landing before the refresh cycle does. It is not a hidden fee; it is an operations cost, and operations is not the department comparing quotations.

How large that second pool grows depends on the workload, not on the drive alone. The same QLC part that costs almost nothing to run behind a read-heavy archive can become an expensive choice behind a backup target, a log store or a replication node. Read-intensive, mixed-use and write-intensive drives are separated by precisely this: how much of the day the drive spends writing, and whether those writes arrive in bursts or as a continuous stream. Workload class is the hinge on which the two pools balance.

Endurance is where the pools meet. A QLC drive's rated endurance is generally lower than a TLC drive's at the same capacity, and the figure belongs to the exact order code rather than to the family name. Comparing across classes, or across units — drive writes per day against total bytes written — answers the wrong question; QLC, TLC and pSLC endurance explains why the class label alone decides nothing. The purchase needs the rated figure for the option being shipped, in the unit the datasheet uses, set against the writes the application will actually generate.

When the cache empties, the datasheet changes meaning

Once the write cache is exhausted, the drive stops behaving like the product the capacity price describes and starts behaving like the NAND underneath it. The cache — the fast, SLC-like area that absorbs incoming writes — exists to make bursty traffic look effortless. It fills when the host writes more than it can hold, and it stays full when the drive never gets enough idle time to fold that data into QLC. From that point new writes go directly into QLC cells at their native program rate, garbage collection competes with the host for the same media, and the drive settles at whatever sustained write rate the NAND can support. That rate is lower than the burst rate, and it holds for as long as the write stream continues.

Latency rises for reads as well as writes, because commands queue behind busy media. Write amplification increases, so every host write spends more of the endurance budget than the datasheet arithmetic assumed. The transition is not a fault: the drive is doing what its design says it does outside the envelope the price assumed. A buyer who measured only burst behavior reads the first sustained write as a failure and opens a ticket. A buyer who planned for the transition never sees it, because the workload never crosses it.

Where the arithmetic reverses

The per-terabyte advantage reverses on write volume per unit of capacity, not on capacity, price or brand.

Start with the shape of the write stream. If the application writes in short bursts separated by idle periods, the cache absorbs each burst and folds it back before the next one arrives, and buying on capacity holds. If the writes are continuous — a log tier, an ingest pipeline, a replication target — the cache never recovers, the drive lives permanently at its sustained rate, and the cheap capacity is paid for by the write path.

Next, the endurance budget. Project the writes the application will generate across the service life, compare them with the rated endurance of the exact order code, and insist on margin. If the projection exceeds the rating before the refresh cycle, the drive will be replaced mid-life; the replacement, the labor and the risk of doing it under load belong in the comparison, and they usually erase the per-terabyte advantage that started the discussion.

Third, the events that arrive without warning. Rebuilds, resynchronization, snapshots and restores are write storms, and they land precisely when the array is already degraded. When the recovery plan depends on writing quickly, the capacity tier is the wrong place to save money.

The rule that settles the comparison

Price the drive by the writes it must absorb over its service life, not by the terabytes it holds. It requires measured input, not a projection from a presentation. Take the busiest quarter of write volume the application has actually produced, extend it across the intended service years, and hold the result against the rated endurance of the exact order code in the datasheet's own unit. Then run the second test: can the drive absorb its busiest measured day without the cache emptying and staying empty? If both answers pass with margin, the capacity-led purchase is sound. If either fails, the saving is a loan against the write path, and the interest is paid in replacements, latency and engineering attention for the rest of the deployment.

What belongs on the purchase order

A purchase order that states capacity and part number leaves the write assumption blank, and a blank assumption is filled by whoever ships. Put the workload on the order rather than in the covering email, so that engineering, receiving and the seller are all comparing the same thing.

The lines that do the work:

• The workload declaration — measured daily writes, the read-to-write ratio, whether the stream is bursty or continuous, and the longest sustained write the application can produce.
• The endurance basis — the rated figure for the exact order code, its unit, and the datasheet revision it came from, not the family name or the headline on the product page.
• The sustained write behavior after the cache is exhausted, stated in writing by the seller with the conditions under which it applies. This is the answer a burst figure never gives.
• The interface and form factor, confirmed against the chassis rather than inferred from the model number. U.2 and U.3 compatibility lists what has to be settled with the server or backplane vendor before the order leaves.
• The power-loss requirement, when data in flight matters. What to verify in an SSD's power-loss protection is a specification to be checked, not a feature assumed from the product class.

None of these lines asks for a discount. They ask for the two numbers that decide whether the drive is cheap: what it costs to put the capacity in the rack, and what it costs to keep the writes inside it. If the seller cannot put sustained behavior and the endurance basis in writing, the capacity figure is the only verified part of the offer — and it was never the part in doubt.