How to Write to SSDs [pdf]

5/16/2026 at 6:00:21 AM

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.

by lia323

5/18/2026 at 1:43:50 AM

Amazing Paper!

by eekdrnf9904

5/16/2026 at 1:09:16 PM

fantastic paper!

by zipy124

5/16/2026 at 12:23:42 PM

> we introduce a NoWA (No Write Amplification) pattern that guarantees SSD WAF = 1, even at full device utilization.

That they got this to work on regular commodity SSDs (from multiple vendors) is very impressive.

by maxi-k

5/16/2026 at 3:36:36 PM

Very interesting indeed. They mention a very simple rule of thumb (not new to this work AIUI but still worthwhile) that suggests arranging data into blocks that will all be discarded in bulk at the same time. Doing this is generally already enough to make a dent into write-amplification.

by zozbot234

5/16/2026 at 8:09:07 PM

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.

by lia323

5/16/2026 at 7:30:39 AM

This seems to miss a reference to Zoned XFS, which is the Linux file system that actually looked into this kind of data placement at the file system layer. The paper includes numbers using RocksDB:https://dl.acm.org/doi/10.1145/3725783.3764399

by user01815-2

5/16/2026 at 10:16:15 AM

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.

by lia323

5/16/2026 at 8:13:35 AM

There seems to be more details about the Linux implementation here: https://zonedstorage.io/

by ece

5/17/2026 at 10:15:07 AM

Interesting paper. I only started reading / digesting it, but:

- I'm not sure how to interpret the Figure 1. It says "Flash writes (KB) per page", but it doesn't really say which page sizes were used. AFAIK MySQL has 16K by default, PostgreSQL has 8K, LeanStore has 4K, but that which makes the numbers a bit hard to compare.

- Likewise, I'm a bit unsure about the doublewrite buffering in Postgres, described as "indirect". Postgres doesn't really do doublewrite (we really should, I think), we write pages to WAL and then to data files. I assume that's what is meant by "indirect" in the paper. But this very much depends on the checkpoint frequency and write pattern, as the FPI is written only for the first page change. I wonder if the results in the paper consider this. Maybe the workload is such that it always hits the page just once between checkpoints (i.e. a worst case). Also, the WAL part is nicely sequential, which should play nice with SSDs.

by pgaddict

5/17/2026 at 4:39:40 PM

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.

by lia323

5/15/2026 at 11:43:33 PM

this is the kind of research that creates new db types, or super optimized postgres im not sure yet

by itsthecourier

5/16/2026 at 2:18:44 AM

This paper gives a really nice end-to-end treatment of an entire problem domain that is usually taken piecemeal. Almost all of the techniques mentioned are already used in databases in some form. It won't lead to new database types but it provides a framework for thinking about the write amplification problem.

Not every database architecture will be able to easily take advantage of all these techniques. Some designs are much more easily optimizable than others.

by jandrewrogers

5/16/2026 at 8:05:41 AM

To add to that: some of the techniques are well known to storage experts, but not yet widespread among database engineers. The paper does a great job of explaining the effects on database systems. Great work!

by melhindi

5/16/2026 at 12:52:42 AM

can be both, psql has pluggable storage engines. See any of the numerous columnar or sharding extensions for postgres for examples of prior art.

by vetrom

5/16/2026 at 12:01:11 AM

SMR Hard Drives have very different rules about how you should access them vs conventional hard drives or SSDs. I wonder how much optimizing for SMR drives (Big sequential writes) would also optimize for other drive types.

by Dwedit

5/16/2026 at 1:10:51 AM

The zoned-storage people (whom shingled folks were a subsect of) seemed pretty ok with the FDP (Flexible Data Placement - TP4146b) scheme that finally finally finally got hammered out for NVMe 2.1 (August 2024). It was also designed to satisfy the open-channel flash people as well.

It's a fairly simple concept that lets you have some write-affinity, that lets you declare when writing that this write should be associated with other writes with the same FDP number, a tagging.

I'm not fully convinced this really is as good as what the open channel flash people wanted. But drive manufacturers were never voluntarily going to give up really complex Flash Translation Layers. They all want to be value add, have their expensive fancy controllers keeping the market from commoditizing to just using NAND directly. But FDP does show some very real promises, can have huge read-write-affinity bonuses!

I note that SSDFS filesystem is still out there being improved and maintained, for a file system that tries to take advantage of this all. I'm not sure if it's made the jump to using FDP or is still older much more ornery & never quite loved ZNS specification. I'd love to give it a try but FDP and ZNS drives are not easy to get ahold of, require asking very nicely, and when I last checked required purchasing very expensive fancy enterprise SSD that cost a ton but which had pretty so so performance figures. That was a couple years ago now. https://www.phoronix.com/news/Linux-SSDFS-NVMe-ZNS-SSDs https://news.ycombinator.com/item?id=34939248

The paper here is wonderful & beautiful. FDP should make this kind of thing so so so much easierz should remove so many of the downsides of drive usage mentioned here. If only it were available. I'd really love it if driver reviewers would look at and comment on the feature matrix drives have, and comment on FDP, but generally, it feels like there's no ask, little pull and thus no push, for an obvious and basically free to implement zero cost improvement that makes everything vastly better. Alas. Can't wait. Hopefully drive prices are better by 2031 & FDP is finally available. Fingers crossed.

by jauntywundrkind

5/16/2026 at 10:10:35 AM

Speaking of zoned SSDs (ZNS or FDP), are any of these available today without having to ‘call sales’? I wanted to experiment with this maybe 2 years back and there was nothing.

by geertj

5/16/2026 at 6:23:48 PM

With apologies for outing your bio here so pointedly,

> Storage nerd @ Google

Vendors, are you listening?

(And the software would/could be so much better... If this were available to play with)

by jauntywundrkind

5/17/2026 at 11:42:34 PM

To be clear, I was asking from a personal perspective, unrelated to my role at Google.

by geertj

5/16/2026 at 6:23:58 PM

SMR drives shouldn't be used with write heavy databases. Or really any write heavy workload. They are best used for storing lots of read only.

by UltraSane

5/16/2026 at 7:10:09 AM

The paper shows a through analysis of write amplification and slowdown/wear with large databases (800GB) on a single machine. Databases are MySQL and postgres. As already commended, this can lead to an optimized storage table format for greater performance. Nice!

I would expect that a similar analysis can be done for sqlite, maybe with a different dataset, single write thread..

by schobi

5/16/2026 at 10:25:29 AM

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

by lia323

5/16/2026 at 9:32:46 AM

Thanks for sharing!

by ifiokambrose

5/16/2026 at 6:21:28 PM

Enterprise storage systems solve this problem by having writes go to 8GB or more of NVRAM and then get consolidated and flushed to the SSDs. I wish consumer grade systems used a similar system.

by UltraSane

5/16/2026 at 7:50:43 PM

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.

by lia323

5/16/2026 at 8:34:26 PM

In enterprise storage systems the NVRAM write buffer is centrally located in the controllers and the proprietary filesystem is designed to use it. This means SSDs very rarely have to handle small writes.

by UltraSane

5/16/2026 at 9:05:09 PM

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.

by lia323

5/16/2026 at 11:23:01 PM

Enterprise storage designs are actually really interesting and varied. Two of the most interesting are VAST Data which was designed specifically for QLC flash and Infinidat which uses 3 controllers and 3TB of RAM for cache

by UltraSane

5/17/2026 at 4:42:59 PM

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

by lia323

5/16/2026 at 2:08:56 PM

[flagged]

by hpcgroup

5/15/2026 at 11:12:36 PM

I feel fooled after clicking on the link and seeing that this PDF is downloading (or just literally writing to my SSD) until I realized that this is the point

by dofi4ka

5/16/2026 at 6:33:28 AM

This is why im using ramdisk for a browser cache.

by patrulek