Proxmox VE vs TrueNAS

Both of these can run virtual machines, both can run containers, and both do ZFS. Comparing their feature lists is how people end up installing the wrong one. The decision that matters is which one boots first, because that is the one that owns the disk controller, and only one thing can own a disk controller.

Proxmox VE is a Debian hypervisor with storage attached. TrueNAS is a storage appliance with a hypervisor attached. That sounds symmetrical and is not: Proxmox expects you to treat it as a Linux box and SSH into it, while TrueNAS treats the operating system as an appliance surface you are asked not to modify. Install packages on a TrueNAS host and the next update reverts them.

Read the table below for three rows in particular. The idle RAM figures are documented minimums, not observed footprints, because both projects are operating systems rather than apps. The container_count of 0 on both means neither is something you deploy into an existing stack. And the ports tell you they collide: TrueNAS binds 80 and 443 by default, Proxmox serves its UI on 8006, which is why the two of them coexist far more easily than most people expect.

Which one should be the base layer#

Ask what the machine does when the storage is idle. If the answer is "nothing", put TrueNAS on the metal. If the answer includes a Home Assistant VM, an OPNsense firewall, a Windows box for one stubborn application, or a Docker host you want to snapshot before every upgrade, put Proxmox on the metal and let TrueNAS be a guest.

The reason is not capability. TrueNAS runs VMs and Docker apps perfectly well. The reason is that the two products have very different ideas about how much you are allowed to change. Proxmox gives you a pve-no-subscription repository and a normal apt system; you can install smartmontools, tmux and a custom systemd unit and nothing objects. TrueNAS gives you a middleware API and a read-only-ish root, and the correct response to "how do I install X on TrueNAS" is usually "you do not". That constraint is a feature when the box is a filer. It is a wall when the box is your whole homelab.

There is a third answer that people skip past too quickly: two machines. A cheap N150 mini PC running Proxmox for services and a separate four-bay box running TrueNAS removes the entire passthrough problem, and the power draw difference is often under 15 watts, which What a home server costs to run puts in money. If you are sizing a first build, Mini PC vs NAS vs used enterprise is the argument for splitting.

HBA passthrough, and what happens when you get it wrong#

If TrueNAS is a guest, ZFS must talk to real disks. That means passing through the entire storage controller as a PCI device, not passing individual drives.

On the Proxmox host, enable IOMMU. On a ZFS-root install you edit /etc/kernel/cmdline and run proxmox-boot-tool refresh; on a GRUB install you edit /etc/default/grub and run update-grub:

# Intel
intel_iommu=on iommu=pt
# AMD
amd_iommu=on iommu=pt

Reboot, then confirm the controller is in a group of its own:

dmesg | grep -e DMAR -e IOMMU
lspci -nnk | grep -A3 -i 'SAS\|RAID bus controller'
find /sys/kernel/iommu_groups/ -type l | sort

Add it to the VM as hostpci0: 0000:03:00,pcie=1 with machine type q35 and OVMF firmware, and set balloon: 0. Ballooning is the quiet killer here: Proxmox reclaims memory from the guest, ZFS inside the guest has already handed that memory to ARC, and you get a storage VM that swaps under load for no visible reason.

Now the part vendor-friendly guides leave out. The failure mode of doing this wrong is not "slower". If you give TrueNAS virtual disks backed by a file or a zvol on the host, you are running ZFS on top of ZFS. The guest computes checksums against blocks that the host has already copied-on-written, write amplification multiplies, and the guest's cache flush requests terminate at the host rather than at the drive's platters. The guest also cannot read SMART attributes or drive serial numbers, so when a disk starts failing TrueNAS reports a healthy pool and you have no way to identify which physical drive to pull. A power loss in that configuration can leave a pool that imports with errors, and ZFS's usual advantage (it tells you exactly which file is damaged) becomes ZFS telling you the whole pool is damaged.

Two more traps. The onboard SATA controller usually cannot be passed through, because your Proxmox boot device is on it. And USB-attached disks are not a substitute; ZFS on USB enclosures loses drives under load and you will spend weekends on it.

The enterprise repository prompt that stops every new install#

Proxmox ships pointing at enterprise.proxmox.com, which requires a subscription key. Without one, apt update ends in an authentication error and a nag modal appears at every login. A remarkable number of people conclude the product is crippled without paying. It is not; the no-subscription channel is a supported repository.

Proxmox VE 9 uses deb822 files, so the fix is not editing sources.list:

# disable the enterprise repos
mv /etc/apt/sources.list.d/pve-enterprise.sources{,.disabled}
mv /etc/apt/sources.list.d/ceph.sources{,.disabled}

cat > /etc/apt/sources.list.d/pve-no-subscription.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

apt update && apt full-upgrade

TrueNAS has no equivalent, because its updates come through the middleware and the free build is Community Edition by name. That is one genuine point in TrueNAS's favor for a first-time operator: nothing about the free install looks broken on day one.

How much RAM ZFS really wants, in numbers#

Proxmox's ZFS documentation says start at 8 GB and budget roughly 1 GB per TB of pool. TrueNAS documents 8 GB as an absolute floor with about 1 GB more per drive past eight, plus a 16 GB or larger dedicated boot device.

The number that surprises people is ARC's default. Upstream OpenZFS gives ARC half of system RAM. Proxmox installs from the 8.1 ISO onward instead write a zfs_arc_max into /etc/modprobe.d/zfs.conf targeting 10 percent of RAM with a 16 GiB ceiling. Systems that were upgraded from older releases, or pools created after installation on an ext4 root, keep the upstream default. On a 64 GB host that is a 32 GB swing in what remains for guests, and it shows up as VMs being OOM-killed on a machine you thought had headroom. Check it before you size anything:

cat /sys/module/zfs/parameters/zfs_arc_max
arc_summary | head -30

A workable split for a 32 GB host running Proxmox with a TrueNAS guest on 24 TB raw: 4 GB for the hypervisor, 16 GB assigned to the TrueNAS VM with ballooning off, 12 GB left for everything else. If that feels tight, it is, and that is the honest cost of ZFS. ZFS, btrfs, mdadm or one disk covers when btrfs or plain mdadm is the better trade.

Consumer SSDs die faster under Proxmox than under TrueNAS#

This one gets omitted from almost every "Proxmox homelab" post. Proxmox keeps its cluster configuration in a SQLite database behind the /etc/pve FUSE mount, and Corosync replicates it in real time. Add ZFS metadata updates and guest journals and you have constant small synchronous writes. On a DRAM-less consumer QLC drive, the wearout figure in Node > Disks climbs several percent per month. People report boot SSDs at 30 percent wearout inside a year on otherwise idle clusters.

TrueNAS is gentler on its boot device by design, because the OS runs from a config database that is written rarely. The exposure moves elsewhere: TrueNAS puts app data in an ix-apps dataset on a pool you nominate, and that choice is sticky. Moving it later means redeploying applications.

If you are buying, get a drive with power loss protection for the Proxmox boot and VM pools. Used enterprise SATA SSDs at 240 GB or 480 GB cost less than a new consumer NVMe and will outlive the machine. Track it with Scrutiny rather than checking the web UI once a quarter.

Get the TrueNAS product name right before you follow a guide#

TrueNAS 25.04 "Fangtooth" folded CORE and SCALE into one product line. The free build is TrueNAS Community Edition; the paid, hardware-backed build is TrueNAS Enterprise. As of September 2026 the current release is 25.10 "Goldeye" on 25.10.7, with TrueNAS 26 in beta.

Three consequences:

• If a tutorial mentions Kubernetes, Helm charts, catalog "trains" or an ix-applications dataset, it predates the 24.10 Electric Eel release that replaced k3s with Docker. The UI it describes does not exist.
• If you are still on FreeBSD CORE 13.0 or 13.3, the UI upgrade path only reaches 24.04. For anything newer the documented route is a clean ISO install plus a configuration restore, which is the kind of thing An update strategy that does not lose data exists to make you rehearse, and it is one-way: activating a FreeBSD boot environment afterwards can break the system.
• 25.10 removed the built-in certificate authority, removed SMART test scheduling from the UI, and switched to the open NVIDIA drivers, which support Turing and newer only. A P400 or GTX 1050 used for transcoding stops being available to apps after that upgrade.

Verdict by situation#

What to do next#

Decide the base layer first, then buy the HBA, then buy RAM. In that order, because the RAM figure depends on the pool size and the pool size depends on how many drives the controller carries.

If Proxmox is the base, budget for enterprise SSDs and read Choosing home server hardware before ordering. If TrueNAS is the base and you plan to run apps on it, understand that you are choosing an app platform that has been rebuilt twice in three years, and that Docker Engine on a plain Debian VM is the more stable place for anything you depend on daily. Either way, snapshots on the same pool are not backups, a point The backup blind spot quantifies: pair this with Backups that actually restore and send replication somewhere else before you put real data on it. Stack planner will size the RAM total once you know what you intend to run.