How to Write to SSDs

This paper demonstrates that redesigning database systems to adopt out-of-place writes, exemplified by a modified LeanStore, significantly reduces write amplification and boosts throughput across diverse OLTP benchmarks while enabling support for modern SSD interfaces like ZNS and FDP.

The Gist

Here is an explanation of the paper "How to Write to SSDs," translated into simple, everyday language using analogies.

The Big Problem: The "Rewriting the Whole Book" Syndrome

Imagine you have a massive library (your database) where you need to update a single sentence in a book.

How current systems work (In-Place Writes):
In most modern databases, if you want to change a sentence, the librarian doesn't just cross out the old words and write new ones. Because the book is glued to the shelf, they have to:

1. Copy the whole page to a temporary "safety note" (Double-Write Buffer) just in case the power goes out while they are writing.
2. Go to the shelf, tear out the old page, and glue a new one in its exact spot.
3. The SSD (the shelf) gets confused: The shelf is actually a magical box that can't erase just one page. To make room for the new page, the shelf has to move other valid pages out of the way, erase the whole block, and then put everything back.

The Result: You wanted to write 1 sentence, but the system ends up moving and rewriting 5 sentences. This is called Write Amplification. It wastes energy, slows you down, and wears out the shelf (the SSD) much faster than it should.

The Solution: The "Moving Truck" Strategy (Out-of-Place Writes)

The authors of this paper propose a radical change: Stop trying to rewrite the book on the shelf. Instead, treat the storage like a moving truck.

When you need to update a sentence:

1. Don't touch the old page. Just leave it there.
2. Write the new sentence on a fresh piece of paper and put it in a new spot in the truck.
3. Update the index (the map) to say, "The new sentence is now at Location B."
4. Later, when the truck is full, the librarian goes back, finds all the old, useless pages (the ones that were replaced), and throws them away in one big sweep.

This simple shift allows the database to control where and how data is written, rather than letting the SSD guess.

The 5 Magic Tricks (Optimizations)

To make this "Moving Truck" strategy work perfectly, the authors added five specific tricks to the librarian's routine:

1. The "Folding" Trick (Compression & Page Packing)

• The Problem: If you compress a page of text, it becomes smaller. If you try to fit a small note into a big slot, you waste space. If you try to fit two small notes into one big slot, they might get squished and hard to read later.
• The Fix: The librarian folds the notes perfectly and packs them tightly into 4KB boxes (standard slots). This ensures that when they need to read a note, they only have to open one box, not two. It saves space and makes reading faster.

2. The "Expiration Date" Trick (Grouping by Deathtime)

• The Problem: Some pages in the library are updated every second (hot data), while others are never touched again (cold data). If you mix them in the same box, when the librarian needs to throw away the "hot" box later, they accidentally have to move the "cold" pages too.
• The Fix: The librarian looks at the "expiration date" of the data. They put all the "hot" pages in one box and all the "cold" pages in another. When the "hot" box expires, they can throw the whole box away without moving a single "cold" page. This prevents unnecessary moving.

3. The "Special Truck" Trick (ZNS Support)

• The Concept: Some modern SSDs (called ZNS) are like special trucks that come with pre-assigned zones. You can't just throw things anywhere; you must fill Zone A, then Zone B.
• The Fix: The authors' system is designed to talk directly to these special trucks. Because the truck forces you to write in order, the librarian never has to move things around. The "Write Amplification" drops to zero.

4. The "Perfect Fit" Trick (Aligning GC Units)

• The Problem: The librarian's "trash can" (Database Garbage Collection) might be 10 feet wide, but the SSD's "trash chute" is only 5 feet wide. If they don't match, the trash gets stuck or has to be moved twice.
• The Fix: The system measures exactly how big the SSD's internal trash chute is and adjusts the librarian's trash can to match it perfectly. This ensures that when they throw something away, it fits perfectly without needing extra moves.

5. The "No-Mess" Pattern (NoWA)

• The Problem: If the librarian is juggling multiple boxes at once, they might accidentally mix up which box belongs to which zone, causing a mess that requires extra cleaning.
• The Fix: The system uses a strict rule: "Don't open a new box until the current one is full." If they must juggle, they add a tiny "compensation" step to ensure the boxes stay perfectly separated. This guarantees that the SSD never has to do extra work to clean up a mess.

The Results: Why Should You Care?

The authors tested this new system (called ZLeanStore) against standard systems like MySQL and PostgreSQL. The results were massive:

• Speed: The system ran 1.6 to 2.2 times faster.
• Wear and Tear: The amount of data written to the SSD was 6 to 9 times less.
  • Analogy: If a normal SSD would last 5 years, this new method could make it last 30 to 45 years (or at least, it would last that long before wearing out).
• Cost: Less writing means less electricity and less money spent replacing broken hard drives.

The Bottom Line

For decades, databases have been trying to write to SSDs the same way they wrote to old spinning hard disks. It's like trying to drive a Formula 1 car on a dirt road.

This paper says: "Stop driving on the dirt road. Build a highway."

By switching to Out-of-Place Writes and using these five smart tricks, databases can finally talk to SSDs in a language they understand. The result is a system that is faster, lasts longer, and wastes almost no energy.

Technical Summary

Here is a detailed technical summary of the paper "How to Write to SSDs" (Extended version accepted to PVLDB 2026).

1. Problem Statement

Modern Database Management Systems (DBMSs) have largely optimized for SSD read performance and internal parallelism but continue to treat SSD writes as if they were writing to traditional Hard Disk Drives (HDDs). This approach leads to two critical issues:

• Excessive Write Amplification (WA): The total number of physical writes to the flash memory is significantly higher than the logical writes issued by the application. This occurs in two layers:
  • DB Layer: In-place update systems (e.g., MySQL, PostgreSQL) use Doublewrite Buffering (DWB) to ensure crash consistency, effectively doubling logical writes.
  • SSD Layer: SSDs perform Garbage Collection (GC) internally. When a block containing valid and invalid pages must be erased, the SSD must relocate valid pages, causing internal write amplification.
• Consequences: High WA drastically reduces SSD lifespan (endurance) and degrades throughput. The paper demonstrates that a standard in-place DBMS can write 4.7× more data to the flash than the user intended, potentially reducing an SSD's 5-year lifespan to under 2 months under heavy load.

The core challenge is that Total WAF = DB WAF × SSD WAF. Optimizing only one layer often worsens the other (e.g., reducing DB writes might force the SSD to perform more internal GC). Furthermore, SSDs lack visibility into workload semantics (hot/cold data patterns), making it impossible for them to optimize GC effectively on their own.

2. Methodology: The Out-of-Place Paradigm

The authors propose a fundamental shift from in-place to out-of-place writes within the DBMS. By decoupling the logical page location from the physical flash location, the DBMS gains full control over write placement. This allows the system to coordinate DB-level and SSD-level optimizations to minimize Total WAF.

The proposed solution, implemented in a modified version of LeanStore (called ZLeanStore), consists of a stack of optimizations:

A. DB-Level Optimizations (Reducing DB WAF)

1. Compression & Page Packing:
   • Compresses pages before writing to reduce volume.
   • Innovation: Uses Page Packing to align compressed pages to 4 KiB boundaries. This prevents read amplification (where a single logical read triggers multiple physical reads due to misalignment) while retaining space savings.
2. Grouping by Deathtime (GDT):
   • Estimates the "deathtime" (expected time until invalidation) of each page based on database semantics (e.g., write timestamps, access patterns).
   • Strategy: Groups pages with similar deathtimes into the same physical zone. This ensures that when a zone is selected for GC, it contains mostly invalid pages, minimizing the "copyback" of valid data.

B. SSD-Level Optimizations (Reducing SSD WAF)

The system adapts its write patterns based on the specific SSD interface available:

1. ZNS (Zoned Namespace) Support:
   • For ZNS SSDs, the DBMS manages zones directly. Since the DB controls GC and enforces sequential writes within zones, internal SSD GC is eliminated, guaranteeing SSD WAF = 1.
2. Aligning GC Units (Standard SSDs):
   • For standard SSDs, the DBMS estimates the SSD's internal GC unit size (e.g., Superblock size).
   • Strategy: Sets the DB's zone size to match the SSD's GC unit. This ensures that pages with the same deathtime are written to the same physical block, preventing the mixing of hot and cold data that triggers inefficient GC.
3. NoWA Pattern (Commodity SSDs):
   • A write pattern designed to guarantee SSD WAF = 1 even on standard SSDs without ZNS/FDP.
   • Mechanism: It prevents "multiplexing" (interleaving writes from different zones into the same physical block) and enforces frequency balance. If an imbalance is detected, the DB performs "compensation writes" to fully invalidate a physical block before the SSD's internal GC is triggered.
4. FDP (Flexible Data Placement) Hints:
   • For FDP-enabled SSDs, the DB uses placement hints (Reclaim Unit Handles) to direct specific zones to specific physical regions, effectively achieving the same result as NoWA but with less overhead.

3. Key Contributions

• Total WAF Metric: The paper argues that minimizing Total WAF (DB × SSD) is the only correct metric, as optimizing one layer in isolation can be counterproductive.
• DBMS as the Orchestrator: It demonstrates that the DBMS, possessing the only complete view of workload semantics, is the optimal layer to manage write patterns, rather than the filesystem or SSD firmware.
• ZLeanStore Prototype: A fully functional out-of-place storage engine that integrates compression, GDT-based GC, and adaptive SSD interface support (ZNS, FDP, Standard).
• NoWA Pattern: A novel algorithm that guarantees SSD WAF = 1 on commodity SSDs without requiring specialized hardware, bridging the gap between standard and ZNS devices.

4. Experimental Results

The system was evaluated on diverse OLTP benchmarks (YCSB-A, TPC-C) across multiple enterprise SSDs (Samsung, Micron, Kioxia, Solidigm) with datasets ranging from 160 GB to 1.6 TB.

• Throughput:
  • YCSB-A: Throughput improved by 1.65× to 2.24× compared to in-place LeanStore.
  • TPC-C (15k warehouses): Throughput improved by 2.45×.
• Write Amplification & Flash Writes:
  • YCSB-A: Flash writes per transaction reduced by 6.2× to 9.8×.
  • TPC-C: Flash writes reduced by 7.2×.
  • Total WAF: Achieved near-optimal values (close to 1.0) across all devices. For example, on a Samsung PM9A3, Total WAF dropped from 4.72 (in-place) to 0.60 (out-of-place + all opts).
• Lifespan: The reduction in flash writes directly translates to a proportional extension of SSD lifespan.
• Robustness: The optimizations maintained high performance across different vendors, capacities, and fill factors (up to 90% full).

5. Significance

• Paradigm Shift: The paper challenges the traditional separation of concerns where DBMSs manage logic and SSDs manage physical storage. It proves that co-design is essential for modern storage efficiency.
• Hardware Agnostic: While ZNS and FDP offer the best results, the proposed NoWA pattern allows commodity SSDs to achieve near-ZNS efficiency without hardware changes, making the solution immediately applicable to existing infrastructure.
• Scalability: The approach scales effectively with dataset size and write intensity, addressing the growing bottleneck of write-heavy OLTP workloads in the era of falling SSD prices and stagnant DRAM costs.
• Future Proofing: The architecture is designed to seamlessly integrate with emerging storage interfaces (ZNS, FDP) and can be adapted for other storage engines (LSM trees) and even traditional disks or SMR drives.

In conclusion, "How to Write to SSDs" establishes that out-of-place writes, combined with workload-aware garbage collection and SSD-aware placement, are not just optional optimizations but essential requirements for maximizing the performance and longevity of modern database systems.