What the controller actually is
NVM Express, the body behind the NVMe standard, describes a typical NVMe SSD as three parts: a PCIe host interface, an SSD controller (for example a processor running firmware) and non-volatile memory such as NAND. A separate NVM Express explainer says the controller bridges the host interface and the physical media. It translates host commands into reads and programs on the flash, and it keeps a data-placement table in its Flash Translation Layer (FTL).
Academic and patent literature describes the FTL the same way. The core job is mapping the logical addresses the operating system uses to physical flash locations. The FTL hides the internal complexity of flash, so the OS can read and write it much as it would a hard disk. A survey of device-level SSD techniques lists address mapping, garbage collection, wear leveling, error correction and bad-block management among the FTL's key functions.
Your PC never sees any of this. Windows sends read and write requests to logical blocks, and the drive's firmware decides where the bits really go. That is why a firmware update can change how a drive behaves without touching the hardware.
One caveat on the original article. It says controllers "usually" use Arm cores. The sources I reviewed confirm that controllers contain processors and run firmware. They don't establish how common Arm is, so treat that detail as plausible but unverified.
Why flash needs a manager
The housekeeping comes from how NAND works. Kingston's technical write-up explains that NAND can be read and written at page level but only erased at block level. Changing data in a page that already holds data means the drive must handle the whole block. The drive can write directly only to a page that is already empty.
The controller therefore works around this constantly:
- Garbage collection. Per a SSD Review primer, this relocates existing data to new locations so the surrounding invalid data can be erased, because only whole blocks can be erased. NVM Express lists garbage collection and wear leveling as controller housekeeping tasks.
- TRIM. The operating system uses TRIM to tell the drive which data is no longer needed. Without it, a deleted file still looks valid to the controller until the OS reuses those sectors. TRIM only informs the drive. It is not an immediate erase command, and the firmware decides when to reclaim the space. (On NVMe drives the equivalent is the Dataset Management command.)
- Wear leveling. Kingston's FAQ says NAND cells eventually wear out, so the controller spreads data across all memory cells to keep any one group from being over-used.
- Error correction and bad-block management. Micron says NAND needs a controller, internal or external, plus firmware for error correction, bad block management and wear leveling. Raw NAND relies on an external host controller for all of these jobs.
The original article also lists scrambling, encryption, data refresh, thermal throttling and SLC caching as controller duties. These are real features on many drives. They are not universal, though, and scrambling, ECC and encryption are separate functions that shouldn't be lumped together. Whether your drive encrypts in hardware depends on the product, so check its documentation.
Over-provisioning: not "a bit" of space
The article says every SSD carries "a bit" of hidden space. Kingston's data shows the amount varies a lot. Its published examples run from about 7% to 28% for client-sized drives, and the capacity is invisible to the host operating system and reserved for the controller. A 1TB-class drive might expose 960GB in a read-intensive configuration or 800GB in a write-intensive one.
That space isn't only for replacing dead blocks. Kingston says the controller uses it as a temporary workspace for garbage collection, reclaiming blocks filled with invalid pages. Kingston also compares drives that differ only in over-provisioning. The ones with less reserve kept the same sequential speeds, but random-write IOPS dropped sharply. That makes over-provisioning a practical tuning lever, not a footnote. Kingston notes that some of its enterprise models let users adjust it through its management tool. That is a vendor-specific capability, not something every drive offers.
DRAM, DRAM-less and Host Memory Buffer
The mapping table has to live somewhere fast. NVM Express says high-performance SSDs use a separate DRAM chip as buffer memory, lower-end drives may integrate a smaller buffer into the controller, and very low-end client drives may use part of host memory instead. That last case is Host Memory Buffer (HMB), which How-To Geek mentions.
Two clarifications are worth making. HMB is an optional NVMe feature, and the NVMe specification requires controllers to work without it. So "DRAM-less" doesn't automatically mean "uses your RAM". Details also vary by vendor and by drive and driver support. The slice of system memory involved is typically small. The mapping table is also not simply a replacement for DRAM, and the tradeoffs differ by workload.
Is it constantly busy?
How-To Geek says controllers are working around the clock. That is directionally true, since the drive handles background reads and writes from Windows and runs its own maintenance. But the idea of a constantly heavy workload overstates it. Kingston's over-provisioning page says garbage collection operates independently of the operating system and is triggered during periods of low activity, periodically, or by a TRIM command. ATP's technical blog likewise says some of its drives run background garbage collection from time to time even without new write commands. Timing and intensity depend on the drive's firmware and on your workload.
What this means when you buy an SSD
The article's advice is to look beyond PCIe generation and headline speeds. That is sound, with some refinement.
- Treat box speeds as a ceiling. NVM Express notes that the host interface sets the maximum possible performance. Real results depend on the number and speed of flash channels, the flash itself, power allocation, and driver and protocol efficiency.
- Don't assume the controller explains everything. Two drives with the same NAND can differ because of firmware, DRAM, over-provisioning and cache design, not only the controller silicon. No specific benchmark comparison accompanied the original article, so this is a general principle, not a measured result.
- Look at sustained and mixed-write testing. The SLC cache, garbage collection and over-provisioning behaviors above all show up when a drive is full or under heavy writes. Independent reviews that test those cases are more informative than a peak sequential number.
- Check the actual specs. Look for DRAM versus DRAM-less, HMB use, hardware encryption support, and endurance ratings in TBW. Kingston notes that endurance depends on NAND, capacity and controller capability and efficiency.
- Keep firmware current if the vendor ships updates. Firmware is the controller's operating logic. Use the manufacturer's own tool or support page, and back up first.
Practical Windows notes
- Windows handles TRIM on supported SSDs automatically, so you generally don't need to intervene. Kingston's FAQ also advises that SSDs never need defragmenting and that automatic defragmentation should be disabled. (Windows normally recognizes SSDs and treats them differently. Check your own system if you have concerns.)
- Don't fill a drive to the brim. More free space gives the controller more room for garbage collection. Kingston's TRIM note says reclaimed invalid pages add to available space.
- A dead controller can leave a drive unreadable even if the flash is fine. That follows logically from the architecture, but it is a general consequence, not a diagnostic rule. Don't assume a failed drive can't be recovered, and don't skip backups because of controller details.
Bottom line
The "tiny computer" description is accurate: a processor, firmware and memory managing a medium that can't be overwritten in place and wears out over time. The main corrections to the popular summary are that over-provisioning varies by drive, HMB is optional and vendor-specific, and background work depends on the drive and workload. When you shop, treat the controller, firmware and memory design as part of the product, not as an invisible detail behind a speed number.