lia323

wow, 3 controllers and 3TB of RAM for cache is pretty wild. I wasn't aware of that design before. Thanks for sharing!

Thanks!

The caption of Figure 1 lists the page size used by each system (i.e., the default configuration).

We use different page sizes across systems, and as you said, it is a bit difficult to compare them directly apples-to-apples. This is actually intentional! Because this also exposes the B-tree index-level write amplification effects. In that sense, Figure 1 kind of suggests that larger page sizes may not necessarily be great for write amplification.

And yes, you are correct regarding Postgres. Instead of having a separate doublewrite buffer file, Postgres relies on WAL full-page writes, which indirectly trigger additional checkpoint writes, so the effect is not entirely straightforward to quantify. To explain that, we discuss how we measured DB WAF for Postgres in Section 10.7 (“How can we calculate DB WAF on other DBMSs?”) of the appendix version: https://arxiv.org/pdf/2603.09927

Regarding the WAL part, yes, the WAL itself is nicely sequential and should generally behave well on SSDs. But once it gets mixed with small random writes that are eventually persisted to flash, it will unfortunately still likely suffer from SSD WAF.

If you are referring to controller-side NVRAM that sits before the SSDs at a higher layer, then yes, you are right that small writes can often be absorbed and consolidated there before reaching flash. Enterprise SSDs themselves seem to employ internal write buffering for a similar purpose, as I mentioned before. However, this still does not fundamentally eliminate GC-induced SSD write amplification once the data is eventually persisted to flash.

I assume NVRAM buffering at that layer will definitely make the write access pattern less skewed from the SSD’s point of view and can therefore reduce WAF. We did not evaluate that kind of storage-stack setup in the paper, though.

The end goal of the NoWA write pattern is conceptually similar to what you described, in the sense that NoWA tries to increase the chance that data becomes invalid together inside the SSD, which is also what mechanisms such as TRIM try to facilitate. The NoWA pattern is more about proactively aligning the application-level GC behavior with the SSD’s internal GC behavior, such that the SSD has little or no valid-page movement left to do internally.

All experiments in the paper were done using enterprise SSDs. Large write buffers inside the SSD can definitely help mask the performance degradation of slow flash writes by absorbing and consolidating updates before flushing to flash, but they do not fundamentally solve write amplification itself.

Unless the write access pattern repeatedly hits the internal write buffer such that many updates are absorbed before they ever need to be persisted to flash.

Thanks! I have not tested SQLite myself, but it would definitely be worthwhile to evaluate as well. SQLite would likely suffer from write amplification in a similar way as MySQL or PostgreSQL, since it is also a page-based DBMS with in-place updates, regardless of the single-writer design.

The degree of the resulting write amplification depends on several factors, including the fill factor, write skewness, and the write rate relative to the SSD characteristics. We discuss this in more detail in Section 10.2, “When should the DBMS care about WAF?” in the extended arXiv version.

There is also this paper on SQLite/mobile storage and zoned devices that may be relevant in this context: https://www.usenix.org/system/files/atc24-hwang.pdf

Thanks for pointing this out. I’ll add the reference to the arXiv version later.

In our paper, we only evaluated with regular XFS (see Section 10.3, “What happens if a filesystem is used?” in the arXiv version), but evaluating Zoned XFS would definitely be interesting as well.

Hi, I’m the first author of the paper. Thanks for the interest and the kind comments.

The extended version is available on arXiv if you’d like more details: https://arxiv.org/pdf/2603.09927

The appendix includes additional details and FAQ-style answers that did not fit into the VLDB version.