For database and storage administrators, the attraction is straightforward: keep a large pool of relatively dense flash while reserving a smaller portion for demanding write traffic. The trade-off is equally concrete. Creating that fast region consumes substantially more QLC capacity than it returns as usable pSLC storage, and both regions still belong to one physical drive.
DapuStor J5060 makes the fast flash region a storage-software decision
DapuStor’s August FMS announcement identified mixed SLC and QLC deployment as a new capability of the J5060 series. Its subsequent explanation describes a “software-defined media configuration”: selected QLC cells operate in pseudo-SLC mode, with no dedicated SLC NAND required. This is a change in how the flash is operated, supported by controller and firmware changes, rather than the addition of a second kind of flash chip.
The terminology explains the capacity bargain. QLC, or quad-level cell, stores four bits per cell, requiring the drive to distinguish 16 states. SLC, or single-level cell, stores one bit using two states. Operating QLC media in pseudo-SLC mode gives up density to obtain faster writes and greater write endurance. As Blocks & Files explains, the underlying cells remain QLC parts; their programming and long-term wear characteristics should not be assumed identical to purpose-built SLC NAND.
Many consumer QLC SSDs already use pSLC as a write cache. Incoming data goes into that faster area and is subsequently moved into denser QLC storage, while cache size can vary. According to Tom’s Hardware, the J5060 instead offers an operator-sized, fixed pSLC region, with the pSLC and QLC regions presented to the host as separate block devices. A block device is a storage destination that software can address directly.
That changes who decides where data belongs. A hidden cache is managed by the SSD; the host-visible J5060 arrangement gives storage software an explicit fast destination. DapuStor names database journals, write-ahead logs, and metadata caches as intended workloads. An administrator could therefore consider placing a suitable write-sensitive workload on pSLC while reserving QLC for bulk data, subject to the application and storage stack supporting that arrangement.
“Permanent” needs a narrow reading here: the fast region is a fixed storage allocation, not merely a temporary landing zone whose contents must be folded into QLC as part of ordinary caching. Whether an administrator can later resize that allocation, and whether doing so requires taking the drive offline or destroying existing data, remains undocumented in the available reporting. A fixed region is established; safe live resizing is not.
The J5060 capacity bargain costs more than the simple four-to-one ratio
The underlying J5060 family spans 15.36TB, 30.72TB, 61.44TB, and 122.88TB. DapuStor’s product specification identifies a 15mm U.2 form factor, PCIe 4.0 x4 connectivity, NVMe 1.4a, and single- and dual-port variants. Those are the base family’s specifications, not confirmation that every capacity and variant has the same mixed-mode options.
The most useful allocation example concerns the 30.72TB model. Tom’s Hardware reports pSLC choices of 400GB, 800GB, and 1.2TB, with the middle option consuming approximately 4TB of QLC-equivalent capacity to provide 800GB of pSLC. That is roughly five units of displaced QLC capacity for each unit of fast storage, rather than the four-to-one ratio suggested by the bit counts alone.
Two different capacity costs are easy to confuse:
| Measure | Meaning in the reported 800GB example |
|---|---|
| Fast-region capacity | Approximately 800GB is available as pSLC. |
| Displaced QLC capacity | Approximately 4TB of QLC capacity is committed to creating that region. |
| Combined capacity reduction | Simple subtraction suggests approximately 3.2TB less total storage than retaining those cells entirely as QLC, before any other provisioning differences. |
The last row is arithmetic from the rounded reported figures, not a published usable-capacity specification. It illustrates why “QLC capacity sacrificed” and “total drive capacity lost” are different quantities. The pSLC region still stores data, just much less of it than the same media would hold in QLC mode.
The published accounts also use percentage labels that should not be treated as a definitive provisioning table. Blocks & Files pairs the 400GB, 800GB, and 1.2TB examples with 8%, 14%, and 20%, while Tom’s Hardware describes QLC capacity costs ranging from roughly 6% to 20%. Those percentages plainly are not the pSLC regions’ shares of a 30.72TB drive: 800GB alone is about 2.6% of that nominal capacity. Without a full allocation table defining each denominator, the concrete 800GB-for-about-4TB example is the safer basis for understanding the trade-off.
For procurement, the implication is that the nominal capacity on a quote is insufficient. The useful comparison is the combination of available QLC capacity and available pSLC capacity after provisioning. A larger fast region may be worthwhile for a demanding write workload, but it also removes bulk capacity that the system might otherwise use.
DapuStor’s write-performance claims need matching workloads
DapuStor says its dual-mode design delivers more than seven times the random-write IOPS of QLC-only operation. It also reports average latency below eight microseconds for 4KB random writes to the pSLC region, and more than 25 times the program/erase cycles of QLC operation. Blocks & Files reports those figures as DapuStor’s claims, not results from its own independent testing.
IOPS measures input/output operations per second; latency measures how long an operation takes. Both can be useful, but only when the operation size and test conditions are understood. The stock J5060’s reported 30,000 random-write IOPS and 35-microsecond write latency use 16KB operations, whereas the sub-eight-microsecond pSLC claim uses 4KB writes. Dividing 35 by eight would therefore produce a misleading improvement ratio, and multiplying the stock 30,000 IOPS by seven would not establish a verified pSLC specification.
The firmware changes explain what DapuStor is trying to improve. The company describes die-level isolation to reduce interference from QLC workloads, optimized SLC reserve allocation to reduce write amplification and improve steady-state behavior, and region-aware I/O scheduling to prioritize latency-sensitive traffic. Write amplification is the additional internal writing a drive performs beyond the data written by the host. These mechanisms address contention and internal work as well as the faster programming available from pSLC.
Their practical value depends on concurrent operation. A storage system that keeps both regions busy needs the fast region to retain useful latency while the QLC region handles its own traffic. DapuStor’s isolation and scheduling claims are relevant to precisely that situation, but the reported headline numbers do not provide a complete sustained, mixed-workload comparison. Average latency also leaves open how much slower the slowest operations become.
Endurance requires a separate distinction. A claim about 25 times as many program/erase cycles describes media cycling, not a published allowance for host writes to the pSLC block device. Tom’s Hardware notes the absence of region-specific DWPD or TBW ratings—drive writes per day and total bytes written. The standard 30.72TB model’s reported 0.5-DWPD rating cannot simply be multiplied by 25 and assigned to the smaller pSLC region.
Consequently, the performance claims justify an evaluation, but not a database sizing calculation or warranty assumption. Buyers need the selected allocation’s sustained performance and write allowance, measured under conditions that resemble the intended deployment.
Separate J5060 block devices still share one failure domain
DapuStor’s architectural argument extends beyond a single SSD. Blocks & Files describes its comparison between a chassis containing 24 dual-mode drives and one containing 23 QLC drives plus a dedicated SLC device. In the latter arrangement, write traffic directed to the single fast drive can concentrate on its PCIe connection. With dual-mode devices, appropriately distributed write traffic can use the connections of multiple drives.
At 800GB of pSLC per drive, 24 drives would provide 19.2TB of aggregate pSLC capacity. That is a straightforward calculation, but it does not imply that one workload can automatically use all of it. The storage software must distribute work across those regions; merely exposing more block devices does not establish an aggregate performance result.
The same qualification applies to DapuStor’s recovery argument. Distributing a fast tier can reduce the amount of fast-tier data concentrated on any one device. It may therefore reduce the scope of recovery compared with a design in which one SLC drive serves many QLC devices. Actual recovery time, however, depends on the system’s redundancy and on what data must be reconstructed.
Separate block devices are not separate physical drives. A failed dual-mode J5060 can take both its pSLC and QLC contents out of service. Die-level isolation intended to reduce performance interference does not establish independent controller, firmware, power, or device-failure boundaries.
That makes failure mapping a material integration requirement. If software sees two storage targets backed by one J5060, its protection scheme needs to preserve their shared physical identity. Treating those targets as independent places for redundant copies would undermine the intended protection. This follows from the shared-drive architecture; it is not a reported defect in any particular Windows Server, Linux, or hypervisor implementation.
DapuStor, Micron, and SanDisk put the write tier in different places
The J5060 belongs to a broader set of approaches to QLC’s write-performance trade-off. Its defining choice is to reserve a fixed fast region within each capacity drive and expose it to storage software. That can place fast capacity alongside bulk capacity without adding a separate write-buffer device, at the cost of reducing the QLC space available on every participating drive.
Micron’s XTR takes the separate-device route. As described by Tom’s Hardware, it uses 176-layer TLC NAND operated entirely in SLC mode and can serve as an optional write buffer for arrays of Micron 6000-series SSDs. Its reported rating reaches 35 DWPD, with 15-microsecond queue-depth-one write latency. Those figures describe that product’s specified role and conditions; they are not directly comparable with DapuStor’s incompletely characterized pSLC measurements.
SanDisk’s UltraQLC approach instead emphasizes Direct Write QLC. SanDisk says it eliminates SLC buffering by enabling power-loss-safe writes on the first pass. That pursues a different objective from DapuStor’s explicitly host-visible fast tier: avoiding a conventional SLC buffering stage rather than reserving part of each drive as an independently addressed pSLC destination.
The decision between these architectures concerns placement and management as much as flash speed. A dedicated write-buffer drive can be provisioned separately from the bulk-capacity drives. DapuStor’s fast tier is tied to each participating J5060’s capacity allocation and physical lifetime. Direct Write QLC changes the write path without offering the same two-region arrangement described here.
None of those differences establishes a winner. DapuStor has not supplied pricing in the available reporting, so the capacity sacrificed to pSLC cannot yet be weighed against the purchase cost of a separate write tier. Nor do the reported latency figures share enough test conditions to support a performance ranking.
What the J5060 means for storage administrators
Administrators considering high-capacity QLC should treat mixed-mode J5060 as a candidate for qualification, particularly where a relatively small, identifiable stream of latency-sensitive writes accompanies a much larger body of data. Existing J5060 owners should not assume the announcement means an ordinary firmware update can safely convert deployed drives: the required commands, supported migration path, and reconfiguration behavior have not been established.
For Windows Server deployments, the outstanding issue is the end-to-end management path. The reporting describes separate host-visible block devices, but does not establish a supported Windows provisioning procedure, a particular driver requirement, or integration with a named storage-management product. It would be premature to offer PowerShell commands or a Disk Management workflow for enabling the feature.
The most useful evaluation requirements follow directly from the documented design:
- Obtain the final usable capacities of both regions for the exact J5060 model and allocation being quoted, instead of budgeting from its QLC-only nominal capacity.
- Require documented provisioning and resizing behavior, including whether an allocation change takes the drive offline or erases existing contents.
- Seek region-specific endurance and warranty terms, rather than converting DapuStor’s program/erase-cycle claim into a host-write allowance.
- Assess pSLC write performance while the QLC region is active, using matching operation sizes and sustained workload conditions.
- Verify that the storage stack identifies both regions as belonging to one physical drive and protects their contents accordingly.
- Confirm mixed-mode firmware availability, operating-system support, and pricing before making the configuration a dependency of a production rollout.
DapuStor’s useful contribution is explicit control over a familiar flash trade-off: administrators can exchange some QLC density for a separately addressable, faster write region inside the same SSD. That is a credible option for workloads with clearly separable capacity and write-latency needs. The production decision now rests on the allocation, endurance, and management specifications that turn this announced capability into something a storage team can provision, protect, and support.