Synology NAS SSD Cache: Streaming and 1GbE Usually See No Gain

The XDA piece is an opinion column, not a benchmark report. The author describes a home NAS used for occasional 4K movie streams, music playback and device backups. By the author's account, SSD caching made no noticeable difference on that system, while upgrading the network did. The column gives no before-and-after throughput figures, so its evidence is a user's experience. Its reasoning, though, lines up closely with how NAS vendors describe their own caching features. That alignment is why the column deserves a closer look.

Synology's SSD Cache Documentation Backs the XDA Complaint​

The clearest support for the XDA argument comes from the company that sells SSD caching as a feature. Synology's Knowledge Center for DSM says that the objective of enabling SSD cache is to increase the performance of random access to a small portion of data that is frequently accessed in the storage space. Every part of that sentence narrows the use case. The access has to be random, the data has to be a small portion of the whole, and it has to be requested frequently.

The same documentation lists the cases the feature won't help. Both large sequential read or write operations (e.g., HD video streaming) and entirely random data reading patterns lack re-reading patterns, and thus will not benefit significantly from SSD caching. Synology's SSD cache white paper for DSM 7.1 is blunter still: SSD cache will not improve performance in scenarios involving sequential access patterns. It adds that gains are expected to be minimal for single channel HD video streaming and surveillance recording.

Synology's defaults reflect that design. According to its help pages, a SSD cache by default only accelerates random I/O and does not accelerate sequential I/O. For general use, the company advises turning on a setting called Skip sequential I/O so that sequential I/O can still pass through to the drives of the storage space. In practice, a Synology cache configured as recommended is built to step aside during the large, continuous transfers that make up most home NAS traffic.

Synology's marketing blog says the same thing. A post on optimising a NAS with SSD cache notes that since large sequential read/write operations such as HD video streaming lack re-reading patterns, such workload patterns cannot benefit much from SSD caching. A vendor that makes and sells NAS SSDs is telling buyers, in several places, that the feature is aimed elsewhere. That matches the XDA writer's experience.

So the XDA column's main claim is not contrarian. It is the vendor's own guidance applied to a typical home setup. The column is useful because the popular advice, that an SSD cache is the easy fix for a slow NAS, rarely includes these caveats.

Why a 4K Movie Stream Never Benefits From a Warm NVMe Cache​

The mechanism explains why the XDA writer saw nothing. A cache only pays off when the data a client asks for is already sitting on the fast tier. That rate is called the cache hit rate. A request that misses the cache falls through to the hard drives, and the SSD adds nothing to it. Synology defines the hit rate for a read-only cache as Accelerated Random Read Counts / Total Random Read Counts * 100%, with an equivalent formula counting reads and writes for a read-write cache.

Take the XDA writer's own example. Streaming a single 4K movie reads one large file from start to finish, once. As the column notes, the file is unlikely to be played again soon, so any copy on the SSD just takes up space. Hard drives handle this kind of long, continuous read well, because the heads aren't jumping across the platters. Speeding up something that is already fast enough for one playback stream gains little.

Big backup copies behave the same way. A multi-gigabyte image copied from a PC to the NAS is a sequential write, typically written once and rarely read back. A Synology community forum user who has run SSD caches made the point in practical terms, saying that large files getting written/read sequentially won't show any improvement in my experience. Especially if those files are written and then not read back right away.

Synology's white paper adds a case that complicates the simple "random I/O good, sequential I/O bad" rule. It says entirely random data reading patterns (e.g. music streaming services with a playlist randomizer in a large music library), both of which lack re-reading patterns, will not benefit significantly from SSD Caching. Shuffling a large music library produces scattered reads, but each track is fetched once before the shuffle moves on. There is no hot set to keep on the SSD. The music streaming the XDA writer mentions fits here too.

That corrects a looseness in the popular advice, and slightly in the XDA column itself, which presents high random IOPS as the thing that makes a cache worthwhile. Randomness alone isn't enough. The workload needs randomness plus repetition: the same small blocks requested again and again. Without repetition, a random workload also misses the cache and lands on the hard drives.

There is also a warm-up period. The forum user noted that it can take some time for the cache to fill (warm) up with enough files to show an effect. A home-lab guide from Hostbor gives similar advice: the best way to see gains is to watch how quickly a routine task (like a backup or indexing job) completes after some days of "learning" from the new cache. Anyone judging a new cache by one file copy the day it was installed is measuring the wrong thing, in the wrong way, too early.

Where SSD Cache Pays Off: VMs, Docker, Databases and Busy File Shares​

The XDA writer does not call caching useless and says outright that it isn't snake oil. The column names the workloads where a cache helps: virtual machines, Linux containers, Docker apps, active databases, and offices or homes where several people hit the NAS at once. Every one of those produces the pattern Synology describes, with small requests scattered across the disk and many of them repeating.

Synology's own framing of the feature matches. Its blog describes the case for caching in terms of applications requiring higher random IOPS or when large amounts of data are written to non-contiguous blocks (e.g., OLTP databases and email services). It pitches the cache as a cheaper alternative to buying an all-SSD system. It also notes that a cache can be mounted to a single storage volume or block-level iSCSI LUN to create a read/write buffer, enhancing random access performance. That last point matters for Windows shops that use a NAS as iSCSI block storage for Hyper-V hosts or other servers. Block storage under virtual disks is exactly the workload caching was built for.

A Synology reseller, SyncTech in Thailand, gives a similar list. It describes SSD cache as most useful for tasks with high Random I/O, such as Virtual Machine, Database, Container, Indexing, and File Server with a large number of simultaneous users. It also points out that backing up large files, recording from CCTV cameras, and streaming video are sequential tasks, which may not benefit much. The dividing line is consistent across Synology's knowledge base, its white paper, its blog and a partner's guidance.

Hard drives struggle with scattered small requests because of their mechanical design. Synology's white paper says admins have traditionally fought random-I/O latency by deploying a larger than necessary number of disks may be deployed to increase the number of heads and reduce the chance of two consecutive reads on the same disk. That approach costs money, power and bays. A cache holding a small hot set on flash is the cheaper answer to the same problem.

There is a middle ground that the XDA column doesn't cover and that matters for backup-heavy users. SyncTech notes that large sequential backup writes may not speed up, but the cache may help with metadata, index, deduplication database, and random I/O data searches. Synology's DSM 7.4 storage specifications also list a feature in the same area: metadata of Btrfs volumes can be pinned to a read-write cache. The file-system bookkeeping stays on flash even when bulk data doesn't. For a NAS with huge folder trees, frequent directory browsing or search indexing, that can improve responsiveness even though the headline file copy speed doesn't change. It's a narrow benefit, but a real one, and it gives a nuanced answer to the "backups don't benefit" rule.

Multi-user contention is the other clear case. Several people working on different files at once turn many individually sequential streams into one scattered pattern at the drive heads. The Synology forum user who had run a 1 TB read-write cache for years reported that I see a noticeable difference when trying to do multiple simultaneous reads and writes, that's where I can see a difference. This is one user's observation, not a controlled test, but it fits the mechanism and Synology's guidance.

The 1GbE Ceiling That No NVMe Drive Can Lift​

The XDA writer's most practical finding had nothing to do with storage. The home network was the bottleneck. Many entry-level and older NAS enclosures ship with a single 1 Gbps Ethernet port, and many consumer LANs top out at the same speed. The column puts the practical ceiling at about 115 MB/s. The arithmetic supports that: 1 gigabit per second is 125 megabytes per second before protocol overhead, and real SMB transfers land a little below that.

The consequence is simple. If the hard drives can already fill a 1GbE link during large sequential copies, as the XDA column says modern SATA drives can, then any faster storage tier behind them hits the same limit. The SSD may be able to deliver data many times faster, but the network can only carry about 115 MB/s. Hostbor's guide says the same about faster networks: SSD caching can't magically make your spinning disks saturate a 10 Gbps connection if your main workload is copying huge ISO images or raw video files. The same guide adds that for large sequential operations, mechanical arrays are already decent.

The XDA writer reports that upgrading the network, which the column describes as introducing a 10 Gb backbone and 2.5 GbE switch ports, made a far bigger difference than the cache ever did. It also notes that many devices on that LAN could already run faster than 1GbE, so the old network was holding them back. WindowsForum has not measured this setup, and the column gives no figures. The theoretical headroom is still large: a 2.5GbE link tops out at roughly 312 MB/s before overhead, about two and a half times a gigabit link. For large-file copies, that change affects every transfer. A read cache only affects the fraction of requests it happens to hit.

Epis Technology, an IT services firm writing about Synology deployments, puts the principle directly: SSD cache should be seen as a way to improve performance, not a way to fix hardware that isn't big enough or network problems. SyncTech likewise says a cache choice should not be based solely on the capacity or speed of the SSD because the performance achieved depends on the workload, RAM, network, storage pool, and the applications used together.

One caution about any network upgrade: every link in the path has to support the faster speed. The NAS port, the switch port, the cabling and the Windows PC's adapter all count. A 2.5GbE NAS connected to a gigabit switch port still runs at gigabit speed. The same applies to the client. A PC copying from a slow internal drive, or writing to one, can be the limit no matter how fast the NAS and network are.

Checking the Real NAS Bottleneck From Windows and DSM​

The XDA column ends with advice that applies to anyone: check what is actually limiting performance before buying an NVMe drive for the NAS. The column gives no procedure. Microsoft's and Synology's documentation, though, provide enough to do the checks without guessing. The steps below are split by where they run. The Windows commands check the client and the SMB connection. The DSM steps apply to Synology NAS units only, and other vendors' interfaces differ.

Confirm link speed and SMB behaviour on the Windows client​

Microsoft documents a set of PowerShell cmdlets for inspecting network adapters and SMB connections. Its SMB Multichannel guide is written for Windows Server and lists Windows 10 among supported client systems. The client-side cmdlets are the ones useful against a NAS.

1. Open PowerShell and run Get-NetAdapter. This lists the PC's network adapters with their status and negotiated link speed. A PC showing 1 Gbps is capped at gigabit throughput to the NAS regardless of storage.
2. Run Get-NetAdapterRSS to see whether the adapter supports Receive Side Scaling, which Microsoft describes as a feature that lets multiple connections spread across multiple CPU cores.
3. Run Get-SmbClientConfiguration | Select EnableMultichannel to confirm that SMB Multichannel is enabled on the client. Microsoft says the feature is on by default.
4. Start a long file copy to the NAS. While it runs, execute Get-SmbConnection to see which SMB dialect the session negotiated, and Get-SmbMultichannelConnection to see whether more than one connection is in use.

Microsoft's documentation explains why the last step matters. Without SMB Multichannel, a single SMB session creates a single TCP connection. Microsoft warns that with one CPU core handling it, this configuration (see Microsoft guidance)… more precisely, Microsoft says it "inherently leads to congestion, especially when many small I/O operations are performed." Microsoft also notes that without Multichannel you cannot combine two 1GbE adapters into 2 Gbps, and that when adapters of different speeds are present, SMB Multichannel uses only the fastest and leaves the slower ones idle.

Two limits apply here. Microsoft's requirements are written for computers running Windows Server, Azure Local or Windows 10. Most NAS appliances run their own SMB server software, and whether a particular NAS supports multichannel depends on the vendor and firmware, which this reporting does not establish. The server-side cmdlets in Microsoft's guide, such as Get-SmbServerConfiguration, apply to Windows file servers, not to a Synology or other appliance.

Run a fair file copy test​

Microsoft's testing guidance includes a precaution that also applies when timing NAS transfers. To avoid measuring RAM caching instead of the storage or network, Microsoft advises copying a data set larger than available memory first as a warm-up, then timing only a second copy. Its method also calls for restarting both systems before each test so conditions match. A quick drag-and-drop of a file small enough to fit in memory can give misleadingly high numbers.

For a NAS, a steady copy rate close to about 115 MB/s on a gigabit link means the network is the limit. Storage upgrades will not change that. A rate well below the link ceiling points elsewhere: to the client drive, CPU load, or genuine disk contention on the NAS.

Read the cache statistics in DSM Storage Manager​

On a Synology NAS that already has a cache, the hit-rate figures show whether the SSD is doing anything useful. Synology's hit-rate formula counts only random reads, or random reads and writes for a read-write cache. A low hit rate under a real workload means most requests go past the SSD to the hard drives. A Geeky Gadgets explainer on Synology caching notes that the metric does not reflect improvements in sequential file transfers, which remain unaffected by SSD caching. A high hit rate on a cache that serves a few random requests while large copies bypass it is not a sign of a faster NAS overall.

For owners still deciding, several Synology-focused guides point to the SSD Cache Advisor in DSM. Epis Technology says the tool can help you figure out if caching will help you based on how you actually use your computer. Hostbor adds that it is not always precise but useful as a starting point for sizing. Running the advisor over a normal week of use costs nothing and answers the XDA writer's question with data from your own system instead of forum advice.

If the evidence does support a cache, Synology's documented setup path runs through Storage Manager: Go to Storage Manager > SSD Cache. Click Create. Select the cache mode (only available for Synology NAS models that support read-write cache). Synology also warns that SSD cache is available on specific models only, and that using incompatible drives may lower the system performance and even cause data loss. Check model support and the Synology Products Compatibility List before buying a drive, not after.

Synology's 400 KiB Rule Makes RAM Part of the SSD Cache Bill​

The XDA writer argues that more RAM is often a better and cheaper upgrade than a cache, especially on a NAS that hasn't reached its memory ceiling. The column describes a hierarchy: CPU cache first, then RAM, then other fast tiers only if more is needed. CPU cache isn't something a NAS owner can upgrade, so for practical purposes the order is RAM first, then flash.

Synology's DSM 7.4 technical specifications add a detail that most "just add an SSD" advice leaves out: the cache consumes RAM. Synology states that SSD cache requires approximately 400 KiB of system memory per 1 GiB of SSD cache, including expandable memory, and no more than 25% of the pre-installed system memory. The index tracking what sits on the SSD has to live in memory.

A rough calculation shows the scale. This is WindowsForum's arithmetic, not a Synology figure. A 1 TiB cache (1,024 GiB) at 400 KiB per GiB needs about 400 MiB of system memory. On a NAS with 2 GB of pre-installed RAM, the 25% ceiling works out to about 512 MiB, which limits usable cache to roughly 1.3 TiB. On a memory-starved entry-level box, a large cache takes a real share of the RAM that DSM, file services and any containers also need. The exact limits for a given model come from its datasheet, which Synology's specifications direct owners to consult.

That supports the XDA writer's ordering, with one qualification. RAM is not always the better upgrade. For a NAS hosting VM disks or iSCSI LUNs with a large working set, flash may do things that a few extra gigabytes of memory cannot. For a home NAS that is running low on memory while also serving files and a handful of apps, adding RAM relieves the immediate pressure, and a cache would add to it. Check memory usage in the NAS's resource monitor before deciding.

Consumer NVMe Drives and the Endurance Cost of Read-Write Caching​

The XDA column's third argument concerns the drives. It says most consumer NVMe SSDs, the kind found in desktops and laptops, aren't built for cache duty. A cache sees constant writes and background flushing that can wear a drive out early. The writer also says a drive actually rated for caching costs well over $100, which by itself ruled out the upgrade for that household. The price claim is the writer's; this article does not verify drive pricing.

The endurance concern holds up for read-write caching and is echoed by others who deploy Synology systems. Epis Technology says not every SSD works well for NAS caching. Cache SSDs have a lot of write cycles and need to be very durable. SyncTech, discussing VM workloads, notes that SSDs with high Endurance should be used, there should be sufficient RAM, and the Network should support speeds according to the Workload. The workloads that justify a cache, such as VMs, databases and busy shares, are the same ones that write to it hardest.

The choice of cache mode also involves data-safety trade-offs. Synology's white paper explains that for read-only cache, the SSDs are configured using · RAID 0. For read-write cache, SSDs are configured using RAID 1 to ensure data integrity in case one SSD fails. A read-only cache holds copies of data already on the hard drives, so losing it costs speed, not files. A read-write cache can hold writes that haven't yet reached the hard drives, which is why Synology mirrors it and why it needs two drives. Hostbor summarises the practical difference: For read-only caches, a power outage is unlikely to cause data loss.

That changes the cost. A redundant read-write cache means buying two endurance-rated SSDs, not one, and giving up the M.2 slots or drive bays they occupy. The Geeky Gadgets explainer also flags power-loss protection as a hardware consideration for cache drives. The XDA writer's objection, that the money buys no extra capacity for the household's files, becomes stronger once the realistic configuration is two drives.

The XDA column does overstate one thing: it implies consumer drives shouldn't be used at all. The column itself concedes they can work as cache, only that it isn't recommended. The evidence supports a narrower warning. Write-heavy read-write caching on a drive not built for sustained writes is where the endurance risk sits, and a vendor-compatible, endurance-rated drive is the safer choice when a cache is justified.

What this means for you​

Measure first: find out whether the NAS is limited by its network, its memory, the client PC or real random-I/O contention on the hard drives, and buy for that limit. For a single-user or family NAS that stores files, streams movies and music and takes device backups, the evidence says an SSD cache is unlikely to be the fix, and a network upgrade or more RAM is the better place to start. Admins running VMs, Docker containers, databases, iSCSI LUNs for Hyper-V hosts, or shares used by many people at once have a legitimate case for a cache. They should still confirm it with hit-rate data and plan for endurance-rated, redundant drives if they choose read-write mode.

Owners who already have a cache installed don't need to rip it out. A read-only cache on a supported drive does no harm to data. It just may not be earning its keep. Check the hit rate over a normal week and decide whether the M.2 slots or bays would be better used for something else, such as an SSD storage pool on models that support one.

• On a NAS with a 1GbE port, large file copies top out at about 115 MB/s, and no SSD cache can raise that ceiling. Check link speed on the Windows PC with Get-NetAdapter and confirm every switch port and cable in the path supports the faster speed you want.
• Synology's documentation says SSD cache targets frequently re-read data accessed randomly. Its own examples of workloads that gain little include single-stream HD video, surveillance recording and randomly shuffled music libraries.
• On Synology systems, the DSM 7.4 specifications say the cache needs about 400 KiB of RAM per 1 GiB of SSD cache, capped at 25% of pre-installed memory. Check memory headroom before adding a large cache.
• Read-write caches on Synology use mirrored SSDs, and the write load falls hardest on the drives. Budget for two endurance-rated, compatible drives rather than one consumer NVMe stick.
• When timing a NAS copy from Windows, follow Microsoft's method: copy a data set larger than available memory as a warm-up, then time a second copy, so RAM caching doesn't skew the result.
• Use DSM's SSD Cache Advisor and the cache hit-rate figures in Storage Manager to judge a cache on your own workload, and give a new cache several days to warm up before deciding it has failed.

The XDA writer's conclusion is less contrarian than the headline makes it sound, and it holds up for the same reason: Synology says the same thing in its knowledge base, white paper and blog. An SSD cache speeds up repeated random access, and most home NAS traffic is one-time sequential reads and writes over a gigabit link that hard drives already fill. As 2.5GbE ports become more common on NAS units, switches and PCs, owners who were told to buy a cache will see a larger gain from networking. The cache will still be worth buying for the smaller group whose VMs, databases and busy shares keep the same data in heavy use.