Proxmox vs TrueNAS vs Unraid: ZFS, btrfs, and Homelab IOPS

By LK Wood IV · Published 2026-05-07 · Updated 2026-09-28 · ~16 min read · St. Louis County, MO

Unraid 7.3.2 ($49 once for six storage devices) if your drives are different sizes, TrueNAS Community Edition 25.10.7 (free) if they match and the box is mostly storage, Proxmox VE 9.2 (free without a subscription) if the box mostly runs VMs. The table below makes that call by workload, drive mix and licence cost, with each fact read from the vendor’s own page on 26 September 2026. My default for a new box with matching drives is TrueNAS; I reach for Unraid when the drives are already bought and do not match.

The rest of the page is the pool underneath, and it moves real-world IOPS more than the OS does. A Proxmox host with the wrong vdev layout will lose to a TrueNAS host with the right one, and vice versa.

A decision tree for the storage backend

Sources, read 26 September 2026: Unraid’s pricing, licensing FAQ, array overview and 7.3.2 release notes; TrueNAS software status, 25.10 version notes, 24.10 release notes, hardware guide and Community Edition page; Proxmox pricing, package repositories, roadmap, Ceph guide and ZFS on Linux. On three-node Ceph, a Proxmox forum cluster-setup thread says a cluster that loses a node stays “degraded” until it returns. A separate homelab Ceph thread says three nodes work but recommends ZFS with storage replication for the simpler home setup.

The backup row is the one most homelabbers underweight. A backup target does not need IOPS; it needs capacity, snapshot semantics and zfs send compatibility with the production pool. A single 8-wide RAIDZ2 with no cache layer is right here, and it is the same topology that would be wrong for a primary pool.

Looking for a TrueNAS alternative? Unraid when the drives do not match, Proxmox when the box is really a VM host, and openmediavault for a low-RAM Debian box, which the NAS OS comparison covers.

I may earn a commission if you buy through these affiliate links. As an Amazon Associate I earn from qualifying purchases.

Complete four-bay builds with dated Newegg prices are on the budget NAS builds page, and the NAS storage calculator shows the usable space of six 16 TB drives before you buy them.

Methodology and sources

Numbers in this article come from my own homelab in St. Louis County, MO between February and early May 2026. The ZFS pool under test is six 16TB Toshiba MG09 drives plus two Intel Optane P5800X 800GB NVMe (one mirror) for SLOG and special vdev experiments, on a Supermicro X11SCH-LN4F with 64GB ECC. Unraid 7.1.2 and TrueNAS Community Edition 25.10.2 ran in turn on the same disks. Proxmox VE 8.4 hosts the production version of the pool. fio was the workload generator. I cite the specific job files inline. The btrfs cache numbers came from a four-NVMe Unraid pool on a separate Mini-ITX node. None of these are synthetic vendor benchmarks. They are runs I logged with date, OS version, ZFS version, and pool topology.

Every version, price, requirement and ZFS default on this page was read from the linked vendor documentation on 26 September 2026. The layout advice is my own. The full list is under Sources at the end.

What changed in the storage layer for 2026

OpenZFS 2.3.0 shipped in January 2025 and is now the floor across all three platforms. Its release notes lead with the three changes that matter most at home: RAIDZ expansion (add a single disk to a RAIDZ vdev without rebuilding), Fast Dedup (a rewrite of deduplication for speed) and Direct IO (reads and writes can bypass the ARC, which helps NVMe pools). The Register’s coverage walks through them.

The FreeBSD Foundation’s deep-dive on RAIDZ expansion is worth reading if you have ever lost a weekend rebuilding a Z2 pool to add capacity. Expansion preserves the original failure tolerance of the vdev — a Z1 pool stays Z1, a Z2 pool stays Z2 — and the operation runs while the pool is online.

It reached homelab users in TrueNAS SCALE 24.10 “Electric Eel” on October 29, 2024 — drive-at-a-time, online, at single, double, or triple parity — after years of development, and it now ships on every current build of all three platforms. This single change kills the strongest historical argument for Unraid’s parity-array model in mid-size labs: you no longer have to choose a mix-any-disk parity array just to keep the option of adding one drive later.

TrueNAS stays on the 2.3 line for now: 25.10.7, released 2 September 2026, ships OpenZFS 2.3.9, and TrueNAS 26, in its third beta since 20 August, integrates OpenZFS 2.4 with hybrid pool support. Proxmox moved past 2.3: VE 9.0 shipped OpenZFS 2.3.3 on 5 August 2025, and the current VE 9.2, released 21 May 2026, ships ZFS 2.4.

Unraid 7.3 ships OpenZFS 2.4. 7.3.0 launched on 2.4.1 on 12 May 2026, and 7.3.2, the current stable release, moved to 2.4.3 on 8 July. 7.3.3 is at its second release candidate (24 September) with 2.4.4.

What still differs is the UI, the defaults and the features each platform chooses to expose.

ZFS vs btrfs vs ZFS-on-Unraid: the tradeoffs

There are three real filesystems you will choose from in 2026, and they map to different operational philosophies.

The “ZFS requires 1 GB of RAM per 1 TB of storage” rule is not a requirement. Unraid’s ZFS documentation calls it “outdated advice”, and Proxmox’s ZFS page keeps a milder form as a starting point for its ARC cap: “at least 2 GiB Base + 1 GiB/TiB-Storage”. Treat that as a floor to tune from. ARC scales to whatever RAM you give it, and the benefit drops off fast above your active working set.

The “btrfs RAID 5/6 is experimental” warning is still alive in 2026 and not resolved. Unraid’s cache pool documentation flags it explicitly and says ZFS provides more mature support for those parity profiles.

For a four-drive NVMe cache pool on Unraid that mixes, say, a 1TB drive with three 2TB drives, btrfs RAID 1 uses the space: about 3.5TB usable. ZFS sizes each vdev to its smallest disk, the same rule that sends most people to Unraid’s parity array in the first place. For everything else, ZFS is the right answer.

RAIDZ vs mirrors: where the IOPS live

The single biggest performance lever in a ZFS pool is vdev geometry. RAIDZ vdevs and mirror vdevs are both useful; they are not interchangeable.

Proxmox’s ZFS documentation says it in one line: “A RAIDZ of any redundancy level will approximately behave like a single disk in regard to IOPS”. Mirror vdevs add random IOPS with each pair, and the same page adds that “For running VMs, IOPS is the more important metric in most situations.”

The practical consequence for a six-drive pool:

The table is the math; here is the same six drives as physical bays, so you can see where the capacity and the IOPS actually go.

Here is what that meant on my six-drive test pool with the same six 16TB Toshiba MG09 drives, fio 4K random read at queue depth 32, single client over a local 10GbE link:

Three mirror pairs gave me 2.9× the read IOPS and 6.6× the write IOPS of the 6-wide Z2, at the cost of 16 TB of usable capacity.

RAIDZ wins on bulk media storage, where streaming MB/s is the metric and small-block IOPS does not matter. The NAS & RAID storage calculator opens on the six-drive RAIDZ2 above; switch it to RAID 10 for the three mirror pairs.

For a homelab whose pool is mostly hosting iSCSI for Proxmox or NFS for a Kubernetes node, mirrors. For a homelab whose pool is mostly Plex media and infrequent Time Machine backups, RAIDZ2.

RAID workload worksheet: IOPS, throughput and stripe size

A RAID speed calculator needs a workload, not just a disk count. These worksheets convert a measured array rate or your own hypothetical input and calculate fixed-width RAID stripe geometry. They do not forecast the speed of an unseen array, multiply a drive’s advertised speed by the number of drives, or replace the dated measurements above.

Convert RAID IOPS and throughput

Enter the I/O block size used for the rate you are converting. Dell’s storage-performance guidance distinguishes operations per second from bandwidth and explains why block size and workload affect the comparison. Keep the read/write mix, queue depth and measurement interval consistent when comparing your own runs.

This worksheet uses binary units: 1 KiB = 1,024 bytes; 1 MiB = 1,024 KiB. Its equations are MiB/s = IOPS × block KiB ÷ 1,024 and IOPS = MiB/s × 1,024 ÷ block KiB.

Thus an entered 1,000 IOPS at 4 KiB is 3.90625 MiB/s, while 1,000 IOPS at 64 KiB is 62.5 MiB/s. Conversely, 125 MiB/s at 128 KiB per operation is 1,000 IOPS. These are arithmetic examples, not additional benchmarks. For mixed I/O sizes, use total transferred bytes divided by operation count over the same interval to obtain an average size; an arbitrary nominal block size will not describe that workload.

For a RAID 5 speed calculation, this conversion answers how many bytes correspond to an entered operation rate. It cannot supply that rate from RAID level alone. Random versus sequential access, read/write mix, caching and the controller can change the measured result. Measure the assembled array under the intended workload before using the number for a performance decision.

Calculate a RAID 5 or RAID 6 full data stripe

Storage tools use “stripe size” in different ways. Oracle’s I/O configuration guide distinguishes per-drive stripe depth from width across the striped set. Here chunk size means the bytes contributed by one drive, and full data stripe means only the data chunks, excluding parity. Check your controller’s terminology before transferring a setting.

For one fixed-width RAID 5/6 group, full data stripe KiB = (drives − parity) × chunk KiB, using one parity chunk for RAID 5 or two for RAID 6, as described in Dell’s RAID-level definitions.

Six drives with 64 KiB chunks give 320 KiB of data per full RAID 5 stripe, or 256 KiB for RAID 6; the physical stripe including parity is 384 KiB in either case. This is a geometry calculation, not a recommended chunk size or a prediction of write speed. It does not model variable-width ZFS RAIDZ records or the Unraid parity array.

For capacity rather than rate conversion, the NAS calculator’s separate RAID 50/60 worksheet handles equal nested spans. Its rebuild-duration worksheet divides reader-entered data by an observed rebuild rate; it does not derive a completion time from the IOPS figures in this article.

NVMe SLOG: when it helps

The SLOG (separate log device) is the most misunderstood ZFS feature in homelab forums. It is not a write cache. It does not speed up most writes. It speeds up exactly one thing: synchronous writes that would otherwise commit to the in-pool ZIL.

A practical Reddit thread on enterprise NVMe SLOGs and TrueNAS forum coverage of when SLOG matters both make the same point: SLOG only helps if your workload calls fsync() a lot. NFS writes from VMware or Proxmox, iSCSI for VM storage, and PostgreSQL with synchronous_commit=on are the real winners. For the home case the TrueNAS thread is blunt: an “SMB-file-sharing, Linux-ISO-seeding, video streaming workload does not need and will not benefit from a SLOG.”

On my pool, fio with --sync=1 --rw=randwrite --bs=4k against an NFS-mounted dataset went from 318 IOPS without SLOG to 4,840 IOPS with a mirrored pair of Optane P5800X drives configured as SLOG. The same workload with --sync=0 (async) showed no measurable difference, because async writes never touch the ZIL.

To see whether yours qualifies, run fio twice against the dataset: a synchronous 4K random write (--sync=1 --rw=randwrite --bs=4k) is the workload a SLOG changes, and the same run with --sync=0 never touches the ZIL, so a SLOG cannot change it. The OpenZFS workload-tuning guide recommends a SLOG when “your workload involves fsync or O_SYNC and your pool is backed by mechanical storage”.

The drive matters. A SLOG device must have power-loss protection (PLP) and very low write latency. A consumer NVMe drive without PLP is the wrong part for it.

The discontinued Intel Optane P1600X is one documented example: Intel lists Enhanced Power Loss Data Protection and 1,292 TBW. Size is not the constraint: TrueNAS’s hardware guide says “A high-endurance, low-latency device between 8 GB and 32 GB is adequate for most modern networks”.

If your pool serves only SMB and other async traffic, skip the SLOG. None of it is synchronous, so none of it touches the log. The optical-cable home setup I use with my $1,500 RTX 5060 Ti build and self-hosted local LLM rig is async-only and runs without a SLOG; adding one bought me nothing on either node.

ARC and L2ARC: the cache hierarchy in 2026

ARC is ZFS’s adaptive read cache in RAM. L2ARC is the optional SSD-backed second tier. How much RAM ARC may take by default differs on each platform, and it moved twice in two years.

TrueNAS moved first. The TrueNAS SCALE 24.04 release notes list “ZFS ARC memory allocations are now identical to TrueNAS CORE”, and the community thread that tracks it describes the 50% Linux ceiling lifting at that release. Upstream followed in 2.3. The 2.2 zfs(4) man page uses half of system memory under Linux and, under FreeBSD, “the larger of all_system_memory - 1 GiB and 5/8 × all_system_memory”; the 2.3 man page applies that larger figure everywhere.

Proxmox VE 8.1 and newer write their own cap at install instead: 10% of host memory, clamped to 16 GiB. Unraid 7.3.0 added a zfs_arc_max control under Settings → Disk Settings → Tunable.

So a 64GB TrueNAS host lets ARC grow to about 63GB when nothing else wants the memory. A 64GB Proxmox host installed on 8.1 or later stops ARC at 6.4GB unless you raise the cap.

On my 64GB box, ARC sits at 48–52GB under load, with the rest reserved for the kernel and the few VMs the host runs. ARC hit rates on a homelab serving iSCSI to three Proxmox nodes are typically 92–98% once warm, which means L2ARC is irrelevant for almost every home use case.

Before adding L2ARC, account for its memory cost. OpenZFS’s caching page says “L2ARC costs RAM” because every cached block needs a header in the ARC. Measure the working set and ARC hit rate first; I would add RAM before L2ARC when the workload still fits in memory. I removed the L2ARC from my main pool last year and saw zero measurable degradation in any workload I run.

What replaced L2ARC in my homelab is the special vdev. A special vdev stores metadata and blocks at or below a configurable threshold on dedicated flash, separate from the main pool. TrueNAS’s fusion-pool guide says metadata vdevs are critical to pool operation and should have equal or greater failure tolerance than the data vdevs.

I run a mirrored pair of Optane drives as the special vdev with special_small_blocks=32K. It puts every block of 32KB or smaller on the flash mirror (zfsprops: “Blocks smaller than or equal to this value will be assigned to the special allocation class”), which covers files that small along with all metadata, with no L2ARC required.

The reason the cache hierarchy is shaped the way it is comes down to one brutal fact: the tiers are orders of magnitude apart in latency, so where a read lands matters far more than how clever any single tier is.

Platform UI differences that still matter

OpenZFS 2.3 normalizes the underlying filesystem; the platforms still expose it differently.

TrueNAS Community Edition 25.10 is my pick when I want to manage ZFS from a UI. Its Storage dashboard links to disks, datasets, vdevs, snapshots and pool functions, while the pool-creation wizard exposes the vdev layout. If you want ZFS without typing zpool or zfs commands, this is the platform.

Proxmox VE 9 treats ZFS as a first-class storage backend for guest disks, and its ZFS documentation is written for the shell: adding a log or cache device is zpool add, and the ARC cap lives in /etc/modprobe.d/zfs.conf. Replication is set per guest. This is the right platform if you want full hypervisor control and are comfortable in a shell.

Unraid has had ZFS pools since 6.12.0 (14 June 2023). 7.0.0 (9 January 2025) added hybrid pools with special vdevs, log devices and dedup subpools, 7.2.0 (29 October 2025) added RAIDZ expansion to the WebGUI (7.1 could do it from the command line), and the 7.3 line moved to OpenZFS 2.4 (7.3.0 on 2.4.1, 7.3.1 on 2.4.2, 7.3.2 on 2.4.3).

The UI handles ZFS pool creation, RAIDZ levels and basic dataset operations, and 7.3.0 added a user-facing control for the ZFS ARC-max size plus a view of corrupted files in pool status, two things that previously meant editing a config or dropping to a shell.

Spare vdevs are still out: Unraid’s ZFS page lists them as “Not supported in Unraid (as of 7.1.2)”, and the 7.2.0 and 7.3 release notes do not add them, so there is no hot spare for a ZFS pool the way TrueNAS offers one. For a Docker or appdata pool beside the parity array this works well; for a primary VM storage pool, TrueNAS or Proxmox give you more control.

The difference comes down to where you want to spend your time: TrueNAS spends it in the UI, Proxmox spends it in the shell, Unraid spends it switching between modes.

What I run today, and why

My production pool in May 2026 is three mirror pairs of 16TB drives, a mirrored pair of Optane P5800X for SLOG, and a mirrored pair of Optane P1600X for the special vdev with special_small_blocks=32K. Compression is zstd-3 on every dataset. Deduplication is off. ARC sits around 50GB. The pool serves iSCSI to a three-node Proxmox cluster, NFS to two TrueNAS Mini machines for replication, and SMB to my desktop. Backup target is a separate 6-drive RAIDZ2 pool on a TrueNAS Mini that only wakes up for nightly zfs send.

Getting the vdev geometry right was 80% of the performance win and getting the special vdev right was the other 15%. The remaining 5% was tuning ARC defaults, which mostly meant leaving them alone on TrueNAS 25.10. None of the platform UI differences mattered as much as the topology choice underneath. On a Proxmox box that is mostly storage, raise the installer’s ARC cap.

Related on TechFuel HQ

• Unraid vs TrueNAS vs OMV vs Proxmox: the NAS OS decision — the four-way comparison with openmediavault, RAM floors and what Proxmox does not do as a NAS
• ZFS on Proxmox: Pool Setup, ARC Tuning, and Scrub Scheduling — the practical commands for creating pools, capping ARC for VM hosts, and automating scrubs
• Proxmox VM Capacity Planner — calculate how many VMs your host can run given ARC allocation, RAM, and vCPU overcommit
• Self-Host a Local LLM on a Single RTX 5060 in 2026
• Self-Hosted Photo Library Showdown 2026: Immich vs PhotoPrism vs Ente
• The $1,500 RTX 5060 Ti Mid-Range 1440p Build for 2026
• More Homelab Guides
• UPS Runtime Calculator

Sources

• The Register — OpenZFS 2.3 release coverage
• FreeBSD Foundation — RAID-Z expansion deep-dive
• OpenZFS 2.3.0 release notes
• OpenZFS zfs(4) man page, 2.2 and 2.3 (ARC defaults); zfsprops(7) (special_small_blocks); Caching and Auxiliary Devices
• TrueNAS software status (25.10.7, 26-BETA.3), 25.10 version notes (OpenZFS 2.3.9), TrueNAS 26 version notes, 24.10 release notes, 24.04 release notes, 25.10 hardware guide, Community Edition naming (25.04)
• Unraid pricing, licensing FAQ, array overview, release notes 6.12.0, 7.0.0, 7.2.0, 7.3.0, 7.3.2, 7.3.3-rc.2
• Proxmox VE pricing, package repositories, roadmap, Ceph guide, ZFS on Linux
• Unraid Cache pools documentation
• Unraid ZFS storage documentation
• TrueNAS forum — ARC behavior change in 24.04+
• TrueNAS forum — SLOG/ZIL discussion
• Reddit r/zfs — Enterprise NVMe SLOG considerations
• Linus Tech Tips — ZFS best practices (RAIDZ vs mirror IOPS math)
• Proxmox forum — ZFS 2.3.0 in Proxmox VE

Building the storage box from scratch? The PC Builder checks drive-bay count, PSU headroom and RAM fit before you order.