Unraid vs TrueNAS vs Synology: How to Choose

The three common answers for a home or small-office file server are not really three products. They are three different bets about how storage grows and what happens when a disk dies. Comparing them on features misses the point; comparing them on expansion and failure behaviour makes the decision almost mechanical.

The three storage models in one paragraph each

Unraid gives every array disk its own independent filesystem and writes each file whole onto one disk. A separate parity disk holds computed parity across the others, which is what allows a failed disk to be rebuilt. Because nothing is striped, disks of different sizes coexist and a single disk can be added at any time. The mechanism, and what it costs, is covered in how Unraid storage works.

TrueNAS is a ZFS appliance operating system. Data is striped across all disks in a RAIDZ group with distributed parity. OpenZFS documents raidz1, raidz2 and raidz3 as tolerating one, two and three device failures respectively, with a minimum group size one larger than the parity count and a recommended group size of three to nine disks. Every block is checksummed, so silent corruption is detected rather than propagated.

Synology DSM is a turnkey appliance: sealed hardware, vendor operating system, Btrfs or ext4 on internal drives, and a support relationship. The DS225+ is the current small two-bay model, rated by Synology for up to 40 TB raw with 20 TB drives and quoting over 282 MB/s sequential read and 217 MB/s sequential write from its own internal testing over its built-in 2.5 gigabit port.

Side by side

	Unraid	TrueNAS (ZFS)	Synology DSM
Layout	Independent disks plus parity	Striped RAIDZ vdevs	Vendor RAID or SHR
Mixed drive sizes	Yes, freely	Usable capacity limited by smallest disk in a vdev	Supported via SHR
Add one disk	Yes, any time	Widens a raidz vdev, or add a whole new vdev	Model and bay limited
Single-file read speed	One disk	Scales with data disks in the vdev	Appliance dependent
Bit-rot detection	Filesystem dependent	Checksums on every block	Btrfs checksums
Loss beyond redundancy	Only the failed disks	The whole pool	The whole volume
Snapshots	On ZFS or BTRFS pools	Native, cheap	Btrfs snapshots
Cost model	Perpetual licence, own hardware	Free software, own hardware	Hardware purchase

Expansion is the decisive difference

This is where most of the regret lives, so it is worth being precise about each one.

Unraid adds a single disk of any size to an existing array from the web interface, provided the licence has a free device slot and the new disk is no larger than the smallest parity disk. There is no re-layout and no rewrite of existing data.

ZFS is stricter. A raidz vdev can now be widened by attaching a device, and OpenZFS documents the consequences clearly: fault tolerance is unchanged, a raidz2 stays a raidz2, and blocks written before the expansion keep their original data-to-parity ratio and are simply spread over more disks. Only newly written blocks use the wider, more efficient ratio. The alternative, and the traditional approach, is to add a whole new vdev of the same layout, which means buying disks in groups. Unraid’s own ZFS documentation makes the same point for ZFS pools created inside Unraid: a single disk cannot be added to an existing vdev from the web interface, so plan the layout for future growth.

Synology sits between the two. Synology Hybrid RAID absorbs mixed drive sizes, but the ceiling is the bay count of the chassis you bought, and adding bays means an expansion unit or a new appliance.

If the growth pattern is “one drive whenever a good deal appears”, Unraid is the only one of the three that matches it without penalty.

Failure behaviour is the second difference

Redundancy levels are comparable. What differs is what a failure beyond the redundancy level actually costs.

Because Unraid does not stripe, a loss that exceeds parity costs the contents of the failed disks only. Every surviving disk still holds a complete, mountable filesystem that can be read on any Linux machine. In a striped RAIDZ pool, losing more devices than the parity level loses the pool, because every file is spread across every disk in the vdev. The same is true of a conventional RAID volume in an appliance.

That asymmetry is the strongest single argument for Unraid on a bulk media array, where the data is large, replaceable in principle, and not worth the cost of a second full copy. It is the weakest argument on data you cannot lose, where the right answer is an off-machine backup regardless of which of the three you run.

Performance, honestly

Unraid reads a single file from a single disk, so single-stream throughput is one disk’s throughput no matter how many disks are in the array. Writes to the array are slower still because of the parity read-modify-write cycle, which is why a cache pool exists.

ZFS is the opposite shape. Streaming bandwidth scales with the number of data disks in a vdev, but OpenZFS is careful to note that with the default 128 KiB record size a block spans every data column, so random-read IOPS works out roughly the same as a single disk however wide the group. The “RAIDZ gives you the IOPS of one disk” rule of thumb is about that default configuration rather than a property of RAIDZ itself, and mirrors remain the better choice when random-read IOPS is the binding constraint.

For a media server, several simultaneous streams from different disks is the workload that matters, and all three handle it. For a virtual machine datastore, none of the parity layouts is the right answer; a mirrored solid-state pool is.

Memory and hardware expectations

The claim that ZFS needs 1 GB of RAM per TB of storage is repeated constantly and Unraid’s documentation calls it a myth outright. ZFS uses RAM for its adaptive replacement cache, and Unraid caps that cache at roughly one eighth of system memory so it cannot starve containers and virtual machines. Size RAM for the workload running on top of the storage, not for the pool size.

Synology removes the hardware question entirely, which is the point of buying one, but it also constrains it: the DS225+ product page directs buyers to Synology’s drive compatibility list before purchasing drives. On a self-built Unraid or TrueNAS box, any drive that reports SMART data is a candidate. Sizing a self-built machine is covered in the Unraid hardware guide.

Which one to buy

Choose Unraid if the array will grow one disk at a time, the drives are a mix of sizes and ages, the bulk of the data is media, and the failure mode that matters is “lose one disk’s worth” rather than “lose everything”. Budget for the licence tier that covers every attached device, including cache SSDs.

Choose TrueNAS if the data is small enough to buy disks in matched groups, snapshots and end-to-end checksums are the point, and replication to a second machine is part of the plan. It is also the better answer when a single dataset needs more sequential throughput than one disk can provide.

Choose Synology if the goal is for storage to stop being a project. The trade is flexibility and drive choice for a supported appliance that a household member can also administer. The DS225+ is the current two-bay model; the older Synology DS223 remains the cheaper two-bay option, and the single-bay Synology DS124 suits a pure backup target where redundancy comes from having a second copy elsewhere.

Whichever way the decision goes, redundancy is not backup in any of the three. Parity, RAIDZ and SHR all protect against a disk dying and none of them protects against a deletion, a bad write or a fire. If Unraid is the answer, the failure path worth reading before it happens is Unraid disk disabled, and the parity calculator will model usable capacity for a given drive mix.