NAS NVMe Cache vs SSD Storage Pool: Which Should You Use?

Quick Summary (TL;DR):
Use NVMe cache when your HDD volume has a proven hot working set that is accessed repeatedly and unpredictably. Use an SSD/NVMe storage pool when specific applications—Docker, databases, VM disks, Immich thumbnails, Plex metadata or active project data—must always live on low-latency storage. Cache is selective: frequently accessed blocks are promoted to SSD and cold blocks remain on HDD. A storage pool is deterministic: everything you place there is on flash all the time. For ordinary large sequential backups, media streaming and one-off file copies, cache often adds little because the data may be read only once. Current Synology guidance says SSD cache is designed primarily to improve random access; a read-only cache can use one SSD, while a read-write cache requires at least two SSDs for fault tolerance. Current QNAP guidance makes the same architectural distinction between SSD cache and an all-SSD storage pool, with the latter recommended for consistently intensive random read/write workloads. The biggest buying mistake is assuming that two M.2 slots automatically support both features: many NAS models restrict M.2 to cache, while others support full storage pools only with specific compatible drives. Verify your exact NAS, SSD model, slot bandwidth and vendor policy before buying.

NVMe Cache vs SSD Storage Pool at a Glance

Feature	NVMe / SSD Cache	SSD / NVMe Storage Pool
Primary data location	HDD pool	SSD/NVMe pool
What gets accelerated	Selected hot blocks	Everything stored on the pool
Performance consistency	Workload/cache-hit dependent	Predictable
Best for	Repeated random I/O	Databases, VMs, containers, active data
Large sequential transfers	Often little benefit	Fast, if network can use it
SSD capacity efficiency	Small cache can accelerate large HDD pool	SSD capacity directly stores data
Failure considerations	Read-write cache needs fault tolerance	Use normal RAID/redundancy as required
Vendor restrictions	Model/SSD dependent	Often more restricted

What an SSD Cache Actually Does

SSD cache sits between the HDD volume and the workload.

The NAS operating system decides which blocks deserve to live on flash based on access patterns.

application / client
        ↓
     SSD cache
   hot blocks here
        ↓
     HDD volume
 complete dataset here

The important point is that the cache does not become a separate user-visible storage pool. The HDD array remains the authoritative storage location.

Read-Only Cache

A read-only cache stores copies of frequently read data.

Current Synology documentation says a read-only cache can be created with a single SSD and is intended to improve random-read performance.

If the SSD fails, the original data still exists on the HDD volume.

This makes read-only cache relatively low-risk because the cache contains disposable copies rather than unique unwritten data.

Read-Write Cache

A read-write cache can accelerate both reads and writes.

Writes can land on SSD first and then be synchronised to the underlying HDD pool.

That creates a very different risk profile because the SSD cache may temporarily contain newer data than the HDD pool.

Current Synology documentation therefore requires at least two SSDs for read-write cache fault tolerance.

UGREEN’s current UGOS Pro guidance similarly warns that delayed write-back introduces data-loss risk and requires the user to acknowledge that risk when creating a read-write cache.

A Write Cache Should Be Treated as Part of the Storage Integrity Chain

If unique data exists temporarily in cache, cache failure is not merely a performance problem.

For write cache, prioritise:

SSD redundancy.
High endurance.
Power-loss protection where appropriate.
UPS protection for the NAS.
Vendor compatibility.
Healthy SSD monitoring.

Synology Automatically Protects a Degraded Read-Write Cache

Current Synology DSM documentation describes an automatic protection mechanism for a degraded read-write cache.

When the cache degrades, DSM can stop caching new I/O and begin synchronising existing cached data back to the HDD pool while services continue operating.

That is useful protection, but it does not remove the need for redundant SSDs, UPS protection or backups.

What an SSD Storage Pool Does

An SSD storage pool is normal primary storage built from SATA SSDs or NVMe drives.

SSD / NVMe pool
├── Docker volumes
├── VM disks
├── databases
├── metadata
├── thumbnails
└── active projects

HDD pool
├── media
├── backups
├── originals
└── archive

Everything placed on the flash pool benefits from SSD latency all the time.

There is no cache-hit decision involved.

The Biggest Difference: Probabilistic vs Deterministic Performance

This is the simplest way to understand the choice.

Cache is probabilistic. Performance depends on whether the requested blocks are currently cached.

An SSD pool is deterministic. If the file/database/VM lives on flash, it receives flash latency every time.

For workloads where latency must be consistently low, a storage pool is usually easier to design and troubleshoot.

Cache Works Best with Repeated Random I/O

SSD cache is most effective when a relatively small working set is accessed repeatedly.

Database indexes.
Frequently used VM blocks.
Web/application data.
Frequently accessed small files.
Repeated metadata reads.

Synology’s current guidance explicitly describes SSD cache as primarily useful for random I/O and recommends using Cache Advisor to analyse actual access patterns before sizing a cache.

Cache Often Disappoints on Large Sequential Workloads

Cache is often a poor investment for:

Nightly large-file backups.
Plex/Jellyfin Direct Play.
One-off photo/video imports.
Archive copies.
Large files read once.

These workloads stream large amounts of data sequentially and may never request the same blocks again before they leave cache.

Larger HDDs or faster networking can produce more visible improvement.

Synology Cache Advisor: Measure Before You Buy

Synology currently recommends running SSD Cache Advisor on an existing volume to estimate the hot-data working set.

Its current guidance says the initial analysis takes at least seven days and can run for up to 30 days.

That is a better sizing method than buying the largest SSD that fits the slot.

Cache Size Should Follow the Working Set, Not the HDD Pool Size

A 40TB HDD pool does not necessarily need a 4TB cache.

If the frequently reused random data is only 300GB, a much smaller cache may capture most of the benefit.

Conversely, a 256GB cache can thrash constantly if the active working set is several terabytes.

SSD Cache Consumes System RAM

Cache metadata needs memory.

Current Synology DSM guidance says approximately 400KB of system memory is required per 1GB of SSD cache.

Current QNAP QTS 5.x documentation also ties maximum cache size to installed RAM; for example, its table lists at least 2GB RAM for a 1TB cache and at least 4GB for a 4TB cache.

So buying huge cache SSDs without checking RAM requirements can waste money.

A Storage Pool Does Not Need Cache Metadata

An SSD pool is simply normal storage.

Its RAM requirements come from the filesystem, applications and normal NAS operation rather than a separate cache index.

That can make a dedicated pool more straightforward on a NAS with limited memory.

Docker Usually Benefits More from an SSD Pool Than Cache

Docker application data often consists of many small files, databases and logs.

Putting Docker volumes directly on SSD/NVMe gives guaranteed low latency.

A cache may eventually learn those blocks, but application performance can change as the cache fills/evicts data.

For a NAS that runs many containers, a mirrored flash pool is usually the cleaner architecture.

VMs Strongly Favour a Storage Pool

Virtual-machine disks generate sustained random reads/writes.

QNAP’s own current comparison recommends an all-SSD storage pool for applications that require consistent intensive random read/write access.

Cache can improve VM performance, but if the VMs are important and active all day, putting their disks directly on SSD/NVMe removes uncertainty.

Databases Favour a Storage Pool

PostgreSQL, MariaDB and similar databases are latency-sensitive.

For Immich, Home Assistant history, Nextcloud and self-hosted applications, a flash pool can provide predictable database latency while bulk user files remain on HDD.

Plex and Jellyfin: Cache the Metadata, Not the Movies

Movie files are large sequential data and normally do not need SSD caching.

Put these on HDD:

Movies.
TV episodes.
Music library.

Put these on SSD/NVMe if possible:

Plex/Jellyfin database.
Posters/artwork.
Preview thumbnails.
Application files.
Temporary transcode data where appropriate.

Immich Is a Perfect Hybrid-Storage Example

Immich combines huge sequential storage with latency-sensitive application data.

HDD pool
original photos + videos

SSD/NVMe pool
PostgreSQL
thumbnails
Docker data
application working data

This is usually easier to optimise than placing the whole photo library on HDD and hoping cache catches the right blocks.

Read-Only Cache Makes Sense for Shared Read-Heavy Data

A read-only cache can be attractive when many clients repeatedly request the same small files.

Web content.
Shared documents.
Repeated software/package files.
Read-heavy project assets.

The risk is lower than read-write cache because the HDD volume already contains the authoritative data.

Write Cache Needs High-Endurance SSDs

Write-back cache can generate heavy SSD write amplification.

Compare:

TBW or DWPD endurance.
Warranty conditions.
Sustained random-write consistency.
Thermal behaviour.
Power-loss protection.

A cheap consumer NVMe SSD optimised for desktop burst speed may be a poor choice for constant NAS write cache.

Our next hardware guide compares suitable SSDs: Best NVMe SSDs for NAS Cache and Containers.

A Read-Write Cache Should Be Redundant

Current Synology DSM supports read-write cache only on fault-tolerant SSD RAID types such as RAID 1/5/6/10.

For the common two-M.2-slot home NAS, that typically means a mirrored pair.

Do not sacrifice write-cache redundancy simply to increase cache capacity.

An SSD Storage Pool Also Needs Redundancy

Flash is not immune to failure.

If the pool stores databases, VM disks and container data, use RAID/redundancy appropriate to the platform and maintain backups.

Two NVMe SSDs in RAID 1 are often a good home-server application pool because one SSD can fail without immediately taking every container offline.

Two M.2 Slots Do Not Guarantee Storage-Pool Support

This is the most important compatibility warning.

A NAS can have two physical M.2 slots but support:

Cache only.
Cache plus storage pools.
Storage pools only with approved SSDs.
Different functions depending on firmware/OS version.

Always check the exact current vendor documentation before buying SSDs.

Synology M.2 Storage Pools Are Model- and Drive-Specific

Current Synology DSM documentation separates M.2 cache support from M.2 storage-pool support.

Some current Plus-series models support M.2 storage pools, while other models expose M.2 only for cache.

Synology also applies compatibility requirements to the SSD models that can be used for supported M.2 storage pools.

Do not buy generic M.2 drives based solely on the slot count.

QNAP Offers Cache, All-SSD Pools and Qtier

QNAP exposes three distinct architectures on supported QTS systems:

SSD cache: HDD pool remains primary storage.
All-SSD storage pool: applications/data live directly on SSD.
Qtier: SSD and HDD tiers exist in one pool and QTS automatically migrates hot/cold data.

Qtier is not the same as cache. It physically moves data between storage tiers based on access patterns rather than simply maintaining cached copies.

Qtier Can Make Sense When the Hot Dataset Changes Over Time

If today’s frequently used files become tomorrow’s cold archive, automated tiering can be useful.

For a small home server where you already know exactly which workloads need SSD performance, separate SSD and HDD pools are often easier to understand.

UGREEN Supports Read-Only and Read-Write SSD Cache on Supported NASync Models

Current UGOS Pro guidance documents both read-only and read-write SSD cache on supported NASync hardware with M.2 slots.

UGREEN also supports using SSDs and HDDs as separate storage pools on appropriate models.

As with Synology and QNAP, verify the exact model and current firmware because functionality differs across the NASync range.

Slot Bandwidth Can Limit NVMe Performance

A 7GB/s desktop NVMe SSD does not guarantee 7GB/s inside a NAS.

M.2 slots can be wired as PCIe x1, x2 or x4 and may use different PCIe generations.

Before paying for flagship SSD performance, check:

PCIe generation.
Lane count per slot.
Whether lanes are shared.
Maximum supported SSD size.
Thermal/heatsink requirements.

For the broader HDD/SATA/NVMe upgrade decision, see HDD vs SATA SSD vs NVMe for NAS: Which Upgrade Pays Off?.

The Network Can Hide the Difference

One 2.5GbE link has only 312.5MB/s raw line rate.

One 10GbE link has 1.25GB/s raw line rate.

A fast NVMe pool can greatly exceed either internally.

That does not make NVMe pointless—VMs, databases and containers operate locally on the NAS—but do not expect desktop-NVMe sequential numbers through a slower Ethernet link.

NVMe Cache Does Not Increase Your User Storage Capacity

Two 2TB NVMe SSDs used as cache do not normally give you an extra 4TB user share.

The cache accelerates the HDD volume; its capacity is dedicated to caching.

If you need more usable flash storage, create a supported SSD pool instead.

A Storage Pool Can Be a Better Use of Expensive SSD Capacity

Suppose you buy two 2TB NVMe drives.

As mirrored read-write cache they may provide roughly 2TB of cache capacity.

As a mirrored storage pool they can provide roughly 2TB of persistent low-latency application storage.

If your actual hot application dataset is only 500GB, the storage-pool approach may deliver more predictable value.

When Cache Is the Better Use of Two NVMe Slots

The HDD pool is very large.
The hot working set changes frequently.
Many users repeatedly access small files.
You cannot easily move applications/data to another volume.
The NAS does not support M.2 storage pools.
Cache Advisor / monitoring shows a high potential hit rate.

When a Storage Pool Is the Better Use of Two NVMe Slots

You run Docker.
You run VMs.
You host databases.
You use Immich heavily.
You need predictable application latency.
You know exactly which data should be on flash.
The NAS supports M.2 storage pools with your SSDs.

When Neither Upgrade Is Worth It

Your NAS mainly performs large sequential backups.
You only use Plex/Jellyfin Direct Play.
The system is limited by 1GbE.
The NAS CPU is already the bottleneck.
You are running out of HDD capacity.
You have insufficient RAM for your applications.

In those cases, networking, RAM or larger HDDs may deliver better value.

Do Not Oversize Cache Just Because SSDs Are Cheap

A cache much larger than the working set gives diminishing returns while consuming RAM and SSD endurance.

Measure first, size second.

Synology’s Cache Advisor exists for exactly this reason, and QNAP also provides SSD profiling/over-provisioning tools for supported systems.

Over-Provisioning Can Help Sustained SSD Performance

Leaving spare flash capacity gives the SSD controller more room for garbage collection and wear levelling.

QNAP currently supports configurable SSD extra over-provisioning on supported cache, Qtier and SSD volume configurations.

This can improve sustained random-write consistency at the cost of usable SSD capacity.

Cooling Matters for Both Cache and Pools

Cache can be particularly write-intensive and NVMe controllers may run hot under constant I/O.

Use the vendor heatsink where specified and monitor SSD temperature.

A drive that repeatedly thermal-throttles can defeat the point of buying high-performance NVMe.

Compatibility Matters More Than Benchmark Speed

Before buying NVMe SSDs, check:

Exact NAS model.
Exact SSD model.
Current firmware/DSM/QTS/UGOS version.
Cache support.
Storage-pool support.
Maximum SSD capacity.
Heatsink requirements.
Slot PCIe bandwidth.
Endurance requirement.

Our compatibility guide covers this separately: NAS Drive Compatibility: What to Check on Synology, UGREEN and QNAP.

A Practical Cache vs Pool Decision Matrix

Workload	Better option	Why
Large sequential backups	Neither / HDD + faster network	Low cache reuse
Plex movie files	HDD	Sequential streaming
Plex metadata	SSD/NVMe pool	Predictable small-file latency
Docker containers	SSD/NVMe pool	Guaranteed flash latency
VM disks	SSD/NVMe pool	Consistent random I/O
PostgreSQL/MariaDB	SSD/NVMe pool	Latency-sensitive
Immich originals	HDD	Capacity-first
Immich database/thumbnails	SSD/NVMe pool	Random I/O
Repeated shared small files	Cache	High cache reuse
Changing hot dataset across huge HDD pool	Cache / Qtier	Automatic hot-data acceleration
NAS supports cache but not M.2 pool	Cache	Only supported M.2 use

NAS NVMe Cache vs SSD Storage Pool: The Bottom Line

Use cache when you want to accelerate an existing large HDD pool without deciding manually which data belongs on SSD. It works best when the same small/random working set is accessed repeatedly.

Use a flash storage pool when specific workloads must always be fast. Docker, VMs, databases, metadata and application data benefit from predictable low latency more than from probabilistic cache hits.

Read-only cache is simpler and lower-risk. Read-write cache can improve write performance but needs redundant, high-endurance SSDs and should be protected by a UPS.

Do not assume M.2 slots support both jobs. Synology, QNAP, UGREEN and other vendors vary cache/storage-pool functionality by model, firmware and SSD compatibility.

For most advanced home NAS systems, the cleanest architecture is still simple: HDD RAID for bulk data and a mirrored SSD/NVMe pool for applications. Add cache only when monitoring proves that the HDD workload has enough repeated random I/O to justify it.