Best NVMe SSD for NAS cache (and app pools)

Your NAS has two empty M.2 slots. The tempting move is to fill them, click Cache and expect everything to fly. The better move is to ask what you want to feel faster: the apps you run, repeated reads from hard drives, or a workload waiting for durable writes.

For a small homelab, start with an SSD pool for apps and VMs. Choose Samsung 990 PRO 2TB for that job, WD Red SN700 2TB for a NAS-focused drive, SN700 4TB for more capacity and total write endurance, or Crucial T500 1TB for a smaller project with onboard DRAM. Buy cache only when you can name the bottleneck.

Specs come from the makers; pool and cache guidance comes from the NAS and ZFS documentation.

Need more M.2 sockets for those SSDs? Our NVMe PCIe expansion-card guide compares host bifurcation with an onboard PCIe switch, including the slot map that determines which drives appear.

Quick picks: give each SSD a job

• Best app/VM pool: Samsung 990 PRO 2TB. TLC flash, 2GB of LPDDR4 and a PCIe 4.0 interface make it a sensible starting point for active application storage on a compatible host. Use a matching pair when you want a mirrored pool.
• Best NAS-branded: WD Red SN700 2TB. Its published 2,500TBW rating and NAS-focused design are the attraction. Pick it for the workload and compatibility, rather than chasing a newer PCIe generation.
• Best total endurance: WD Red SN700 4TB. The 5,100TBW rating is the largest in this shortlist, alongside twice the capacity of the 2TB models. That makes it useful for a larger active-data pool with sustained writes.
• Best for a smaller pool: Crucial T500 1TB. Keep TLC and onboard DRAM while buying the capacity your app collection needs. Leave room for VM disks, databases and snapshots to grow.

The parts lists offer alternatives. Choose the model and capacity for your pool; you don’t need all four drives.

App pool, read cache or SLOG?

These names describe different jobs. Pick the job before the SSD.

What you want to improve	Start here	What the SSD does
App data, VM disks and frequently used project files	A separate SSD data pool	Stores the active data directly
Repeated random reads that miss the RAM cache	Investigate L2ARC after sizing RAM	Keeps a second copy of selected read data
Latency from synchronous writes	Investigate a suitable SLOG device	Holds the separate intent log for durable-write acknowledgements
A large, mostly sequential file copy	Find the storage or network limit first	Extra cache may leave the actual bottleneck untouched

SLOG and L2ARC rarely belong at the top of a small homelab’s shopping list. An SSD pool for apps and VMs is often the more useful upgrade: you decide exactly which data lives on it. TrueNAS’s ZFS primer explicitly describes separate SSD and HDD pools as a potentially more efficient layout for active and rarely used data.

Keep the bulk files on hard drives and put the busy application data on SSDs. Our NAS-drive guide covers the capacity tier; the RAID, snapshots and backups guide covers protecting both tiers.

Compare capacity and write endurance

SSD / exact model	Capacity	Interface	Maker DRAM specification	Published TBW	Equivalent full-drive writes*
Samsung 990 PRO · MZ-V9P2T0B/AM	2TB	PCIe 4.0 x4	2GB LPDDR4	1,200TB	600
WD Red SN700 · WDS200T1R0C	2TB	PCIe 3.0 x4	Not stated in the cited brief	2,500TB	1,250
WD Red SN700 · WDS400T1R0C	4TB	PCIe 3.0 x4	Not stated in the cited brief	5,100TB	1,275
Crucial T500 · CT1000T500SSD8	1TB	PCIe 4.0 x4	LPDDR4; 1GB per 1TB of NAND	600TB	600

Equivalent full-drive writes = published TBW divided by the advertised decimal capacity in TB. This compares the write allowance across capacities; it doesn’t predict a failure date.

The 4TB SN700’s bigger total allowance comes largely with its bigger capacity. Per TB of storage, the two SN700 models are close. Choose 4TB because you need the room and total write budget, rather than expecting a dramatic change in endurance per TB.

All four models have a five-year limited warranty; the makers’ endurance and warranty conditions still apply. Samsung and Crucial specify time or TBW, whichever comes first. Read the Samsung 990 PRO datasheet, WD Red SN700 product brief and Micron’s T500 product flyer for the capacity-specific figures.

First: does your NAS accept the drive for this job?

Synology: the model and DSM rules come first

The DS225+ has no M.2 slots, so skip an NVMe purchase for that box. Our UGREEN DXP2800 vs Synology DS225+ comparison covers the expansion differences; the DS225+ datasheet lists its SATA drive support.

For an M.2-equipped Synology, separate cache support from M.2 storage-pool support. Synology’s 2025-and-later drive policy gives DSM 7.3 more flexibility with third-party HDDs and 2.5-inch SATA SSDs. M.2 NVMe still has its own compatibility requirements for new pools and caches.

The official M.2 pool requirements say to use compatible Synology M.2 SSDs on supported models. Start with the compatibility list for your exact NAS and DSM version. This consumer-drive shortlist is aimed at compatible open-platform hosts and NAS configurations, rather than a blanket Synology upgrade list.

UGREEN: two slots, two possible roles

UGREEN lists two M.2 SSD slots on both the DXP2800 and DXP4800 Plus. The DXP4800 Plus documentation describes using its NVMe slots for cache or a dedicated SSD storage pool, including containers and VMs.

Choose the role in the NAS storage software, then follow that model’s drive and installation guidance. A pair reserved for an app pool is a different layout from a pair assigned to HDD cache. Plan the layout before moving data, and keep a backup ready for a pool change.

For a DIY NAS, M.2 uses the motherboard or an appropriate PCIe adapter. A SATA expansion card won’t create an NVMe connection; our SATA/HBA guide explains the separate SATA/SAS side of the build.

Why an app pool is usually the happier first upgrade

Containers, VM images and active project directories give you a clear destination for the SSDs. Put those datasets on the SSD pool and leave the big media/archive collection on HDDs. You can then judge the upgrade with the app or VM you actually use.

For important active data, a mirrored pair gives you drive-failure redundancy. It still needs snapshots and a separate backup. Decide how much usable capacity the project needs before filling both M.2 slots with the smallest drives you can find.

The 990 PRO 2TB is the default app-pool pick for its capacity, TLC and explicitly documented DRAM. The T500 1TB is the smaller alternative when your active data fits comfortably. The SN700 models put more emphasis on the published write allowance. Those are useful buying differences without turning a desktop benchmark into a NAS result.

Boot storage is another job again. Keep it separate from app-pool planning where your platform requires that; our NVMe boot-drive guide covers choosing a system drive.

L2ARC: help RAM, don’t try to replace it

ZFS already uses RAM as its first read cache, ARC. L2ARC adds a second read-cache tier on an SSD. It earns its place when frequently reused data misses ARC and enough of that working set can fit on the SSD.

TrueNAS’s L2ARC explanation describes that overflow role. Its ZFS primer also explains that L2ARC consumes RAM for tracking data. Give the system enough memory first, then inspect cache behavior for your actual workload.

If your NAS mainly serves a film once or receives a long backup stream, start by investigating the workload and network path. Buying a large cache SSD won’t make every transfer faster. If the slow bit is an app’s active dataset, putting that dataset on an SSD pool is the simpler plan.

SLOG: buy power-loss protection, not a gaming badge

A SLOG handles the separate intent log for synchronous writes. It isn’t a general write cache, and it doesn’t turn an HDD pool into an SSD pool. TrueNAS’s SLOG guide explains how the log lets ZFS acknowledge synchronous transactions on non-volatile storage.

For this job, choose a low-latency device with documented in-flight power-loss protection (PLP). OpenZFS’s cache and log guide distinguishes SLOG from asynchronous writes and calls for power-loss protection.

None of the four picks here is our SLOG recommendation. Use them for their app-pool or suitable cache role. If measurements show a synchronous-write bottleneck, shop for an explicitly qualified PLP device instead. A UPS helps with outages, but it doesn’t add PLP circuitry to an SSD.

DRAM, HMB and heat: three different fit checks

Onboard DRAM is memory on the SSD for its controller. It is separate from the NAS’s RAM and ZFS ARC. Samsung explicitly lists the 990 PRO’s DRAM; Micron’s T500 model guide specifies LPDDR4 at 1GB per 1TB of NAND.

Host Memory Buffer (HMB) uses part of the host’s memory for SSD flash management, as explained in Kioxia’s HMB technical brief. Don’t confuse that with onboard DRAM or a NAS read-cache tier. WD’s cited SN700 brief leaves DRAM/HMB unspecified, so its recommendation rests on its documented NAS role and endurance.

Cooling and physical fit matter too. All four picks are M.2 2280 NVMe drives. The selected 990 PRO and T500 variants are the versions without a tall factory heatsink. Use the NAS’s specified thermal pads and covers, keep its airflow clear, and match the SSD/heatsink height to the slot clearance. A heatsink built for a roomy desktop or console can be the wrong shape under a NAS cover.

Make the upgrade earn its slots

Back up the app data, power down before installing M.2 drives, and follow the host’s instructions to create the intended pool or cache. For an app pool, move the relevant datasets and app storage deliberately. Then test the app, check drive health and temperatures during use, and verify a restore of something you care about.

990 PRO 2TB for an app/VM pool. SN700 2TB for the NAS-focused choice. SN700 4TB for more room and total write endurance. T500 1TB for the smaller project with DRAM. Pick the job, buy the capacity, and save the clever cache experiment for a bottleneck you’ve actually found.