Power-loss protection (PLP) explained — and when an SSD must have it

An edge box in the field loses power for half a second. When it comes back, the SSD won't mount — not slow, not partly readable, just gone. The NAND inside is perfectly fine; nearly every byte of data is still sitting there. What broke is the index that says where each byte lives. That's the failure power-loss protection exists to prevent, and it's worse than the one most people picture.

What's actually at risk

To go fast, an SSD keeps two things in volatile DRAM: a write cache of data not yet committed to NAND, and the FTL mapping table — the index that translates logical addresses to physical flash locations [1]. Cut power abruptly and two things can go wrong:

• Uncommitted user data in the cache never reaches NAND, and is lost.
• The FTL table is left half-updated. This is the catastrophic one: a corrupted mapping table can leave the controller unable to find anything, bricking the entire drive even though the NAND cells still hold valid data [1][2].

Losing the last few writes is bad. Losing the map to all the writes is what turns a power blip into a dead drive.

How PLP actually works — hardware and firmware together

Real protection is two layers, and you need both [1][3].

Hardware: the hold-up. On the board sit power-holding capacitors (supercaps or tantalum-polymer). When the supply voltage drops past a threshold, they discharge, giving the controller a brief reserve — typically a few milliseconds. That's enough time to flush the in-flight data and the mapping table from DRAM down into permanent NAND [1].

Firmware: the choreography. Hold-up power is useless without a plan for it. On a power-loss signal the firmware runs an ordered shutdown: suspend garbage collection and wear-levelling so nothing new is started, flush pending writes to a protected NAND region, and atomically finalize the mapping table — journal/commit records, CRC tags, each page marked either fully valid or safely rolled back. The power-management IC reports how much hold-up energy is left, and the controller only begins operations that can finish inside that budget. On the next boot the FTL restarts clean, or is rebuilt from the journal if it was mid-update [3].

That combination is the point. As the engineering literature puts it, real PLP is "strong hardware capacitance and intelligent recovery algorithms, not simply a few caps on the PCB" [3].

Why enterprise and industrial drives include it

Full PLP isn't only insurance — it's what lets a drive cache aggressively and stay correct. With guaranteed hold-up, the drive can acknowledge a write the instant it lands in DRAM (write-back caching), which is how enterprise SSDs hit their IOPS — safe in the knowledge the capacitors will commit it [1]. Take PLP away and that same speed trick becomes a corruption risk: a crash mid-write and the database is inconsistent.

The consumer-drive trap

Be careful with the words on a spec sheet. Many client drives skip full PLP for cost, and some that advertise "power loss immunity" only guarantee that data already at rest won't be damaged by an in-progress write — they do not save the in-flight write or fully protect the mapping table the way enterprise PLP does [1]. Worse, DRAM-less consumer NVMe drives that cache their FTL in host memory (HMB) are the most exposed of all: a system power loss severs the PCIe link and wipes that cache instantly, with no chance to flush it [1]. If the application can lose power mid-write, "power loss immunity" on a consumer drive is not the same guarantee.

A UPS does not replace PLP

This is the most common substitution, and it's wrong. A UPS protects node and facility power against a grid outage. It does nothing when power to one drive is cut locally — a failed PSU in that chassis, a shorted backplane, or a kernel panic severs the SSD long before facility backup matters. A UPS protects the building; PLP protects the write happening inside the drive at the instant power dies.

Where you must have it

Anywhere power can disappear mid-write and no one is there to shut down gracefully: industrial and embedded systems, edge and IoT nodes, in-vehicle and automotive electronics, surveillance recorders, and any database or logging role. (When you also need to size that drive's endurance, pair this with TBW & DWPD.)

Bottom line

PLP protects the one thing whose loss kills a drive: the mapping table. Demand both layers — hold-up capacitors and firmware that commits the FTL atomically — read past "data at rest" marketing, don't lean on a UPS to cover it, and on industrial drives watch the PLP health flag because capacitors age. For unattended and industrial roles we spec SSDs with hardware-plus-firmware PLP as standard — tell us the deployment and we'll confirm exactly what the drive protects, in writing.