For many infrastructure teams, the last decade has been defined by expensive proprietary storage systems and lock-in platforms. VMware’s vSAN and Pure Storage arrays delivered real innovation, but they came at the cost of rigid licensing and ongoing subscription pressure. As budgets tighten and organizations look for greater control, open solutions like Proxmox VE have become attractive as a virtualization layer. The remaining question is: what should back the storage?
While Ceph often dominates the conversation in the Proxmox community, it isn’t always the best fit. For clusters that don’t run at hyperscale, ZFS provides a powerful, and often higher-performance, alternative. It combines filesystem and volume management in one coherent design, offering snapshots, replication, and self-healing — the same building blocks administrators rely on in enterprise platforms.
This article explores how ZFS performs as a storage backend for Proxmox, where it stands relative to vSAN, Pure, and Ceph, and how Klara designs and implements ZFS-based architectures for customers migrating away from enterprise arrays.
Why ZFS is Different
ZFS was designed with data integrity as its foundation. Every block written to disk is protected by a checksum. On reads, that checksum is verified; if corruption is detected and redundancy is available, the block is automatically repaired. This self-healing property is rare, even in proprietary arrays.
But ZFS is not simply about safety. It also consolidates functionality that administrators would otherwise need several tools for. Snapshots, compression, caching, replication, and RAID are all native components. The result is an integrated storage platform where advanced data services are not bolted on but fundamental to the design.
Where Pure Storage markets inline compression and deduplication, ZFS provides several inline compression algorithms, from lightweight LZ4 to higher-ratio ZSTD, as well as on-demand block cloning and online deduplication. Where vSAN promotes software-defined snapshots and clones, ZFS implements them at the filesystem layer with instant copy-on-write operations.
For administrators accustomed to enterprise arrays, ZFS feels familiar — but with the transparency of open tooling.
ZFS and Proxmox
Proxmox integrates directly with ZFS. When creating a VM disk, administrators can place it on a ZFS dataset or volume; when snapshots are taken in the Proxmox UI, ZFS snapshots are invoked under the hood. Replication jobs configured in Proxmox use the zfs send and zfs receive pipeline.
This means that all the operational workflows administrators expect — rolling snapshots for backups, thin clones for test environments, replication to another site — are accessible without additional licensing.
For example, creating a compressed dataset for a VM is as simple as:
zfs create -o compression=zstd tank/vm-201-disk-0
That dataset is then visible in Proxmox as a storage target. Snapshots can be created directly from the Proxmox interface, but they are standard ZFS objects, and can also be managed directly at the CLI:
zfs snapshot tank/vm-201-disk-0@before-upgrade
Cloning that dataset into a writable copy takes only seconds:
zfs clone tank/vm-201-disk-0@before-upgrade tank/vm-201-disk-0-test
This integration lowers the barrier to adopting ZFS in production.
Where ZFS Fits vs Other Enterprise Solutions
Enterprise storage systems, whether hyperconverged (e.g. vSAN) or dedicated arrays (e.g. Pure, NetApp), generally deliver four core capabilities:
- Snapshots and Clones – fast, space-efficient point-in-time copies.
- Inline Data Services – compression, deduplication, encryption, thin provisioning.
- Data Integrity – checksumming, consistency, and durability guarantees.
- Replication – efficient movement of blocks between systems or sites.
ZFS provides each of these functions as native primitives. Snapshots (zfs snapshot) are instantaneous, clones (zfs clone) share blocks until modified, and both can be scripted or driven by Proxmox. Inline compression is configurable per dataset (zfs set compression=zstd-3 pool/db) and can be adjusted without downtime. Every block is checksummed on write and verified on read, with corruption corrected automatically if redundancy exists in the pool. Replication is handled by zfs send/receive, transmitting incremental changes at the block level.
Where enterprise solutions package these features behind management interfaces, ZFS exposes them directly. The cost is that design choices fall to the administrator. For example:
- RAID Layouts: Deciding between mirror vdevs (higher IOPS, lower efficiency) and RAID-Z (higher capacity, less random IOPS), including triple parity not offered by traditional RAID.
- Log and Cache Devices: Adding a dedicated SLOG NVMe (zpool add pool log mirror /dev/nvme0n1 /dev/nvme1n1) for synchronous write workloads, or L2ARC cache devices (zpool add pool cache /dev/nvme2n1) for read-heavy datasets.
- Recordsize Tuning: Matching ZFS recordsize to workload (zfs set recordsize=16K pool/db for OLTP databases vs zfs set recordsize=1M pool/archive for sequential archival data).
These are design parameters enterprise arrays hide, but in ZFS they directly influence performance and resilience. This is where engineering discipline matters: a mis-sized SLOG or poorly chosen recordsize can impact consistency and throughput.
In practice, ZFS on Proxmox is not just a “feature match” with enterprise storage — it’s the same set of core data services, but implemented as open, tunable primitives that must be aligned to workload profiles.
ZFS and Ceph: Different Tools for Different Jobs
Ceph is often the default choice when architects discuss storage for Proxmox at scale. It’s designed as a distributed object and block store, with placement groups, OSDs, MONs, and CRUSH maps determining how data is spread across the cluster. Properly deployed, Ceph scales horizontally, delivering redundancy and capacity growth simply by adding nodes.
That scalability has costs. Ceph introduces operational complexity:
- Service Overhead: Multiple daemons (MON, MDS, OSD) must be managed and tuned.
- Hardware Baseline: Small clusters underperform; generally, five nodes with NVMe journals are considered a minimum for production.
- Latency: Every read and write involves network hops, increasing tail latency.
ZFS, by contrast, can run locally on each node providing failure isolation and direct hardware access. Data services—snapshots, compression, replication—are delivered without distributed coordination.
For clusters of three to ten compute nodes, which is a common Proxmox deployment size, ZFS via NFS or iSCSI provides better performance consistency and simpler operations, while still offering HA capabilities. Replication between nodes or sites is handled with zfs send/receive, not an always-on distributed system, significantly reducing complexity and latency.
In short: if the requirement is hyperscale distributed storage, Ceph may fit. If the requirement is enterprise-class features with predictable performance on smaller clusters, ZFS is the simpler and more efficient tool.
Design Principles for ZFS with Proxmox
Deploying ZFS in production means making design choices that directly affect performance, resilience, and operational behavior. Klara’s engineering methodology starts with workload characterization, then applies ZFS parameters to fit that workload.
Pool Layout
- Mirrors – Best for high random I/O workloads (databases, VDI). Mirrors deliver high IOPS because each mirror pair can service independent reads.
- RAID-Z2/RAID-Z3 – Better for sequential or capacity-driven workloads (archival, bulk VM hosting). Fewer IOPS per spindle, but better usable capacity.
Example: create a pool with three mirrored vdevs:
zpool create tank mirror /dev/sd[b-c] mirror /dev/sd[d-e] mirror /dev/sd[f-g]
SLOG (Separate Intent Log)
For synchronous write-heavy workloads (databases, NFS, VM disks with sync=always) backed by HDDs, a dedicated log device is mandatory. It must be a mirror of power-loss-protected NVMe device.
zpool add tank log mirror /dev/nvme0n1 /dev/nvme1n1
Without a proper SLOG device, synchronous writes are bottlenecked by spinning disks and your application and VM performance will suffer.
ARC and L2ARC
- ARC lives in RAM; ZFS will use most available memory to cache blocks to improve performance. As a rule of thumb: 4 GB of RAM dedicated to the ARC as a minimum. Ensure that you consider the memory that will be consumed by the VMs when sizing the ARC.
- L2ARC extends the ARC with fast SSD/NVMe, configured as:
zpool add tank cache /dev/nvme2n1
L2ARC is most useful when working sets exceed the available memory but are still cache-friendly. Each entry in the L2ARC consumes a small amount of ARC. It is best to avoid having an L2ARC that is more than 4x the size of your ARC.
Recordsize Tuning
Matching recordsize to workload avoids fragmentation and wasted I/O:
- OLTP Databases:
zfs set recordsize=16K tank/pgdata
- VM Images / General Purpose:
zfs set recordsize=64K tank/vmstore
- Sequential/Archive:
zfs set recordsize=1M tank/archive
Conclusion
ZFS with Proxmox is not a “cheaper alternative” — it is a technical solution that implements the same primitives offered by enterprise storage, while offering you greater control over your infrastructure in exchange for requiring more explicit design. Snapshots, replication, compression, and data integrity are not hidden behind licensing tiers; they are commands and properties applied at the filesystem.
The advantage is flexibility and transparency. The cost is that administrators must understand pool layout, recordsize, and caching devices. With proper engineering discipline, ZFS delivers predictable, enterprise-grade storage for Proxmox clusters at small to medium scales, with fewer moving parts than Ceph and more configurability than vendor arrays.
Interested in how ZFS with Proxmox can simplify and accelerate your infrastructure? Get in touch with Klara about a ZFS Storage Design Solution to make the most of this powerful technology pairing.