DapuStor Dual-Mode SSD Trades Capacity for Faster Random Writes

DapuStor has introduced a dual-mode SSD that sacrifices 6% to 20% of its QLC capacity for a permanent, faster pSLC region. The DapuStor dual-mode SSD reportedly delivers more than seven times the random-write performance of an all-QLC configuration.

That is a significant promise for enterprise buyers attracted to QLC’s density but constrained by its write behavior. DapuStor is effectively dividing one physical J5060 into two host-visible storage regions, each optimized for a different job.

The design challenges the established practice of pairing high-capacity QLC drives with separate write-oriented SSDs. However, DapuStor has not published pricing, complete endurance figures, independent dual-mode benchmarks, or a general availability date.

The DapuStor Dual-Mode SSD Splits One Drive Into Two Regions

The central change is not a larger cache. It is a fixed division between high-capacity storage and a separately addressable high-performance region.

DapuStor disclosed the architecture on August 12, following its appearance at FMS: Future of Memory and Storage 2026 in Santa Clara. The company described the design as an SLC plus QLC dual-mode configuration for enterprise workloads.

The implementation does not place dedicated SLC NAND beside QLC chips. Instead, the controller operates selected QLC cells in pseudo-SLC mode, commonly shortened to pSLC.

QLC, or quad-level cell flash, stores four bits in each cell. This raises storage density, but it also requires the controller to distinguish among 16 possible voltage states.

SLC stores one bit per cell and uses only two states. It generally writes faster, tolerates more program and erase cycles, and requires less precise voltage placement.

Pseudo-SLC takes multi-bit NAND and operates it as though it were SLC. The technique gains speed and endurance while giving up much of the NAND’s native capacity.

Consumer QLC drives often use a changing pool of free NAND as an SLC write cache. Incoming data lands there quickly, then moves into denser QLC storage after the initial write.

That arrangement can produce high burst speeds. Performance can fall sharply when the cache fills, the drive becomes crowded, or background folding cannot keep pace.

DapuStor’s approach is different. Its pSLC allocation remains available as a defined region and appears to the host as a separate block device.

The QLC region also appears as its own device. Storage software can therefore direct latency-sensitive writes toward pSLC while leaving bulk data in the denser region.

DapuStor says the media configuration happens through firmware and controller optimization. Its dual-mode design uses die-level isolation, optimized SLC reserve allocation, and region-aware I/O scheduling.

Die-level isolation is intended to reduce interference between QLC operations and pSLC traffic. Reserve allocation manages the NAND assigned to the fast region, while scheduling prioritizes latency-sensitive requests.

Those controls make the design more deliberate than a conventional consumer cache. They also shift responsibility toward storage software, which must identify the right data for each region.

DapuStor uses a 30.72TB drive to illustrate the capacity exchange. In one configuration, roughly 4TB of native QLC capacity becomes 800GB of usable pSLC.

That conversion is closer to a 5:1 ratio than a simple 4:1 calculation suggests. Some physical capacity can be consumed by overprovisioning, metadata, error correction, and other controller requirements.

Other configurations reserve 400GB or 1.2TB of pSLC. Depending on the selected layout, the reported loss equals approximately 6% to 20% of the drive’s QLC capacity.

The company says an all-dual-mode, 24-bay server could provide 19.2TB of aggregate pSLC when each drive contributes 800GB. Every bay would still retain a larger QLC region.

That topology spreads fast storage across all 24 PCIe links. It avoids concentrating write traffic on a smaller number of dedicated cache drives.

The physical device remains a U.2, PCIe 4.0 x4 enterprise SSD. DapuStor’s existing J5060 specifications list capacities from 15.36TB through 122.88TB.

The published J5060 family also supports NVMe 1.4a and dual-port operation. Dual ports matter in enterprise arrays because separate paths can preserve access during controller maintenance or failures.

The significance lies in the logical layout, not the connector. One familiar enterprise drive can now present storage with two distinct performance and capacity profiles.

QLC Write Performance Is the Pressure Point

DapuStor is addressing the weakness that has kept many dense QLC drives confined to read-heavy roles.

Enterprise QLC has become attractive for content repositories, object storage, AI inference datasets, cloud archives, and other capacity-driven systems. These applications benefit from high read throughput and more terabytes per drive bay.

DapuStor describes the standard J5060 as a read-optimized product. Its published specifications rate the family for sequential reads up to 7,300MB/s and 1.5 million random-read IOPS.

The same specifications reveal a much narrower write profile. The stock 30.72TB J5060 is rated for 30,000 random-write IOPS using 16KB operations.

Its rated 16KB random-write latency is 35 microseconds. The family’s endurance rating reaches 0.5 drive writes per day, or DWPD, for some capacities over five years.

DWPD estimates how much of a drive’s capacity can be written daily throughout its warranty period. It does not alone describe latency, workload consistency, or the durability of an individual region.

Independent testing has already shown why the write question matters. A 2025 J5060 review examined the 61.44TB model against Solidigm’s P5336.

The J5060 reached 7.48GB/s in the review’s 128KB sequential-read workload. That result was almost identical to the Solidigm drive’s 7.47GB/s.

The comparison changed under random writes. At 16KB, the J5060 recorded approximately 32,400 IOPS, while the P5336 reached about 51,700 IOPS.

Tail latency also favored the Solidigm drive in that test. The J5060 reached 181.4 milliseconds at the 99.99th percentile, compared with 71.8 milliseconds for the P5336.

A 4KB random-write workload produced approximately 31,900 IOPS on the J5060. The P5336 delivered around 48,000 IOPS and substantially lower tail latency.

These figures came from the standard QLC configuration, not DapuStor’s new pSLC region. They do not invalidate the dual-mode claims.

Instead, they show the problem DapuStor is trying to solve. The J5060 already offers strong read performance and density, but mixed or write-heavy workloads can expose its limits.

Database journals provide one concrete example. A journal records changes before the database commits them to its main structures, protecting consistency after a crash.

Write-ahead logs, or WALs, follow a similar principle. They often involve small, frequent, latency-sensitive writes that can delay later operations if storage response becomes inconsistent.

Metadata caches also generate small updates that carry more operational importance than their size suggests. A large QLC volume can hold the underlying dataset while still struggling with these hot writes.

AI training creates another mixed pattern. The primary dataset can be large and read-intensive, while checkpoints, metadata, logs, and intermediate state generate bursts of writes.

DapuStor proposes keeping the large dataset in QLC and directing the hotter data to pSLC. This puts both storage behaviors behind every drive connection.

The company claims its pSLC region exceeds the QLC-only drive’s random-write performance by more than seven times. It also reports average 4KB random-write latency below eight microseconds.

Those figures are not directly comparable with every published J5060 number. DapuStor’s standard rating uses 16KB random writes, while its sub-eight-microsecond pSLC claim uses 4KB operations.

Queue depth, workload duration, drive fullness, overprovisioning, and steady-state conditions can all affect a storage benchmark. Buyers need matching test parameters before treating the figures as a complete performance comparison.

Even so, the underlying direction is credible. Operating NAND in one-bit mode reduces the number of voltage states and simplifies programming.

The open question is how consistently the DapuStor pSLC QLC SSD sustains that advantage in a full system. That requires independent testing of both regions under concurrent load.

Capacity Versus Performance Is the Real Product Decision

The DapuStor pSLC QLC SSD does not remove the tradeoff between density and speed. It lets operators choose where that tradeoff appears.

Turning QLC cells into pSLC reduces usable capacity because each cell stores fewer bits. The 30.72TB example makes that cost unusually visible.

A buyer does not simply gain 800GB of fast storage. The system gives up roughly 4TB of QLC capacity to create it.

That exchange can still make operational sense. A cluster may otherwise need dedicated high-endurance SSDs for journals, caches, or write buffers.

Separate drives consume bays, PCIe lanes, controller resources, power, and cooling capacity. They can also create concentrated bottlenecks when many capacity drives depend on one fast device.

DapuStor describes a conventional arrangement in which one SLC-oriented drive serves five 30.72TB QLC drives. Bursty traffic can saturate that SLC drive’s link while other links remain underused.

The dual-mode layout distributes fast regions across every participating SSD. A 24-drive system can process writes through 24 pSLC regions instead of funneling them through a few cache devices.

That is the most important systems argument for the DapuStor dual-mode SSD. Its benefit is not limited to the latency of an isolated NAND region.

It also changes parallelism, drive-bay allocation, and failure boundaries. Each pSLC region sits beside the QLC capacity it helps support.

DapuStor says this can reduce the rebuild volume following a device failure by nearly 80% compared with its illustrated 1:5 architecture. That is a company estimate based on a specific topology.

The design does not prevent drive failure. If one dual-mode SSD fails, both its QLC and pSLC regions become unavailable together.

That shared fate creates a different risk. A journal stored in the pSLC region should not be treated as independent protection for data held on the same physical device.

Replication, erasure coding, failover, and backup policies remain necessary. Software must understand that the two block devices share one controller, one enclosure, and one failure domain.

A distributed database could replicate journals across pSLC regions on separate drives. A storage engine could place bulk tables on QLC and latency-sensitive logs on another drive’s pSLC allocation.

The architecture becomes more useful when software makes those relationships explicit. It becomes dangerous when administrators mistake logical separation for physical independence.

DapuStor also claims that the pSLC region supports more than 25 times the program and erase cycles of the QLC region. One-bit operation generally improves NAND endurance, but that claim lacks several purchasing details.

The company has not published a separate DWPD or terabytes-written rating for the pSLC allocation. Buyers cannot yet compare the fast region directly with a dedicated endurance SSD.

They also need to know whether writes to pSLC and QLC share a total warranty allowance. Heavy use of the smaller region can create a very different wear pattern from evenly writing the whole drive.

Host-managed placement adds another consideration. Applications need policies that keep hot writes within the limited pSLC capacity without accidentally filling it.

A fixed region avoids the unpredictable contraction of a dynamic consumer cache. It also creates a hard boundary that software must monitor.

If the region fills, the host cannot assume that idle QLC space will automatically become fast capacity. The behavior depends on DapuStor’s management commands and supported reconfiguration process.

This makes the product a storage architecture decision rather than a drop-in speed upgrade. The capacity sacrifice only pays off when software can use the two regions deliberately.

DapuStor’s Rivals Are Taking Different Routes Around QLC

The competitive question is whether enterprises want fast and dense media inside every drive, or separate tiers with clearer performance roles.

DapuStor’s primary opponent is the conventional split architecture. That design pairs dense capacity SSDs with dedicated write-oriented devices.

Dedicated drives provide clear hardware separation. Administrators can select a high-endurance device, replace it independently, and benchmark it without traffic from a neighboring QLC region.

The downside is concentration. A limited set of cache devices can constrain throughput or expand the amount of data affected by one failure.

DapuStor distributes that fast tier across the array. This trades some capacity from every drive for wider parallelism and a more uniform server configuration.

Micron has pursued the separate-drive model with its XTR line. The product uses TLC NAND entirely in SLC mode and serves as a high-endurance write buffer for capacity SSD arrays.

Micron has rated XTR products for endurance up to 35 DWPD. That positioning emphasizes sustained write durability rather than combining capacity and acceleration in one enclosure.

The separate-device approach lets operators scale cache capacity independently. However, it requires additional drives and careful sizing between the write tier and the capacity tier.

Sandisk has taken another path through its UltraQLC platform. Its Direct Write QLC design sends data directly to QLC instead of relying on an SLC staging cache.

Sandisk says this can preserve writes during power loss while avoiding a later data-folding step. Its UltraQLC architecture prioritizes consistent direct-to-QLC behavior at high capacity.

Direct Write QLC and DapuStor’s dual-mode design address different problems. Sandisk aims to improve the direct QLC path, while DapuStor reserves a distinct low-latency region.

Solidigm’s P5336 provides another comparison point because it competes as a high-density enterprise QLC drive. Independent testing found similar large-block read throughput between it and the standard J5060.

The P5336 performed better in several random-write and tail-latency workloads during that review. The new pSLC mode is DapuStor’s answer to precisely that class of weakness.

NVMe has anticipated configurable media arrangements for years. A presentation at FMS 2019 described a model in which customers could configure one product for different use cases.

Earlier consumer products also experimented with firmware-defined fast and capacity regions. Enmotus and Phison used a split-drive concept in the FuzeDrive P200.

That product never established the model as a mainstream consumer category. Enterprise software, predictable workloads, and large drive capacities now create a different setting.

A database operator can explicitly place a WAL on one block device. A consumer operating system is less likely to expose such placement decisions clearly to ordinary users.

The enterprise market also places greater value on drive bays, predictable latency, controlled failure domains, and workload-specific endurance. Those priorities strengthen DapuStor’s case.

However, they also raise the evidence threshold. Enterprise customers need steady-state results, qualification data, firmware-management documentation, and support commitments.

A clever media configuration is not enough on its own. The DapuStor J5060 performance claims must survive concurrent workloads, near-full conditions, failures, rebuilds, and long-duration writes.

The Missing Specifications Matter More Than the Peak Claim

DapuStor has shown a plausible mechanism, but it has not yet supplied enough information for buyers to compare the product with established storage tiers.

The first gap concerns performance methodology. DapuStor says the pSLC region delivers more than seven times the random-write IOPS of a QLC-only SSD.

The company has not published a complete benchmark configuration with queue depth, thread count, test duration, drive fill level, and steady-state preparation. Those variables can change results materially.

Its latency claim also needs a distribution, not only an average. Database journals and metadata services often care more about the 99.9th or 99.99th percentile than the mean.

An average below eight microseconds can coexist with disruptive latency spikes. Independent tests should report both typical and tail behavior.

The second gap involves endurance. DapuStor says pSLC operation provides more than 25 times the program and erase cycles of QLC operation.

Yet the company has not assigned a region-specific DWPD or total-bytes-written specification. It has not explained whether warranty accounting changes with each allocation.

A 400GB pSLC region receiving continuous journal traffic experiences a concentrated workload. Buyers need to know how the controller rotates physical media and manages wear beyond the visible boundary.

The third gap is configurability. DapuStor calls the allocation flexible, but public material does not clearly explain when administrators select it.

It remains unclear whether the split is factory-set, established during provisioning, or adjustable while the drive is deployed. Live resizing would raise data-migration and consistency questions.

The host command path also needs documentation. Operators must know which NVMe features, vendor commands, drivers, and management utilities create and inspect the regions.

Compatibility matters because enterprise storage stacks vary widely. A design that requires custom orchestration can impose more work than a separate cache drive.

DapuStor mentions host-supported Flexible Data Placement, or FDP, as another way to reduce write amplification. FDP lets a host provide information that helps the SSD place data with similar lifetimes together.

FDP can complement dual-mode media, but the features should not be conflated. A buyer needs to know whether basic pSLC operation depends on FDP-aware software.

The fourth gap concerns independent validation. DapuStor says phased customer testing and initial real-world deployments are underway.

The company has not named those customers or released results from their applications. There is no public production case study showing the two regions under sustained mixed traffic.

The standard J5060 has undergone third-party testing, but those results do not verify the new firmware configuration. Reviewers need access to an actual dual-mode sample.

The fifth gap is commercial availability. The architecture appeared around FMS 2026, where DapuStor presented enterprise SSDs for AI infrastructure.

The company’s FMS preview described products and demonstrations for high-density AI systems. It did not provide a general availability date for this J5060 mode.

Pricing also remains undisclosed. Buyers therefore cannot compare the lost capacity, software requirements, and deployment savings on a complete economic basis.

DapuStor argues that dual-mode drives can reduce acquisition and operating costs by eliminating dedicated SLC devices. That conclusion depends on actual drive pricing and usable-capacity requirements.

A cluster that needs nearly all available QLC capacity may prefer separate cache devices. Another system may gladly exchange capacity for lower write latency and simpler expansion.

The correct comparison is workload-specific. Peak IOPS alone cannot settle it.

What Enterprise Buyers Should Watch Next

Three signals will determine whether the DapuStor dual-mode SSD becomes a practical storage option or remains an interesting firmware demonstration.

The first signal is a complete dual-mode specification. DapuStor should publish supported pSLC allocations, usable QLC capacity, endurance ratings, host commands, and reconfiguration rules.

Region-specific warranty details would strengthen the company’s case. Missing endurance limits would keep dedicated write drives attractive for workloads with strict durability requirements.

The second signal is independent testing under simultaneous pSLC and QLC traffic. Reviewers should measure throughput, average latency, tail latency, and endurance behavior after the drive reaches steady state.

Tests should include database logging, metadata updates, checkpoint writes, bulk reads, and rebuild activity. They should also show what happens when the pSLC region approaches capacity.

Matching block sizes and queue depths will be essential. Without comparable parameters, the reported sevenfold improvement remains a company claim rather than a purchasing metric.

The third signal is a named deployment or general availability announcement. A public customer could show how storage software assigns data between the regions and handles failure.

Availability would also reveal whether dual-mode support ships across the J5060 family or only on selected capacities. It could clarify whether current drives can receive the feature through firmware.

DapuStor’s proposal is technically coherent. It recognizes that dense QLC storage and latency-sensitive writes increasingly occupy the same servers.

The design also makes the capacity cost explicit. Buyers choose a permanent pSLC region instead of depending on a temporary cache that changes with free space.

That predictability is valuable, but it creates new responsibilities. Administrators must place data intentionally, protect both regions from shared failure, and monitor a smaller high-write area.

For developers and infrastructure teams, the immediate action is straightforward: identify which data truly needs low write latency. Journals, WALs, metadata, and checkpoint state are stronger candidates than complete datasets.

Then model whether distributing those writes across every drive beats a separate endurance tier. Include lost QLC capacity, PCIe utilization, replication, rebuild exposure, and software integration.

The DapuStor pSLC QLC SSD offers a compelling answer to QLC’s write limitations. Its next test is whether documented endurance, independent benchmarks, and real deployments support that answer.