Webinar Overview
ZFS and Ceph both deliver reliable storage, but they solve different problems. Ceph distributes data across many nodes (scale-out) while ZFS manages it inside a single system (scale-up). That one architectural difference drives all other metrics: latency, throughput, failure and recovery behavior, how you add capacity, and how much operational effort each demands.
Join Klara's Allan Jude and Clyso's Dan van der Ster for a technical look at how each system works, which workloads suit which technology, and what you trade away when you scale out versus scale up. We'll cover the environments where the choice is obvious, and the ones where it isn't.
We’ll also discuss the case for OSDs on ZFS, what you gain from checksums, snapshots, and replication, against what you pay in duplicated work between ZFS and Ceph, and whether that trade is worth making.
What we'll cover:
- ZFS and Ceph architecture
- Scale-up vs. scale-out storage
- Performance and latency considerations
- Redundancy and failure recovery
- Hardware and networking requirements
- When to choose ZFS vs Ceph, or combine the two
Top Questions from the Session—Answered!
🗨️ How does Ceph compare to ZFS in performance for database workloads?
Databases are latency-sensitive: every commit waits on the fsync of the transaction log, and tail latency (P99) matters more than the average. Ceph, as a scale-out system, adds latency because each write needs to be replicated across the network, and wait for the slowest node to acknowledge. For latency-sensitive workloads that don’t need massive scale, ZFS is often the better fit. One fintech chose ZFS for its low-latency database and, through compression, saved over a million dollars on NVMe drives.
🗨️ What is the purpose of using ZFS underneath Ceph?
Ceph OSDs provide durability through replication; however, Ceph requires quorum, so in a 3-replica setup, if one drive fails and one replica is rebooting, it is not possible to read or write from that group. Using ZFS zvols as underlying storage, a failed drive is hidden from Ceph, and the resilver of a failed drive can complete without the data ever being offline, potentially improving availability in smaller clusters.
🗨️ Any general guidance for using ZFS or Ceph on hypervisors such as Proxmox?
VMs are latency-sensitive: guest sync requests pass straight down to the storage, and boot time is dominated by 4K random I/O, the slowest kind of I/O for any drive. Both ZFS block volumes and Ceph’s RBD block devices work very well for VMs. The deciding factors are usually the rest of the environment. If you have dozens of hypervisors, then Ceph can provide the scale and durability you need. If latency is your most important metric, then ZFS will always have the edge.
Date: October 15, 2026
Time: 11:00 AM EDT
Duration: 50 minutes.
Know someone else who might be interested? Share this entry with them!
Meet the Panellists
Co-founder and Head of Solutions Architecture at Klara Inc., Allan Jude has been on the team since the beginning. Shepherding an amazing team of developers and sysadmins, he is the technical heart of our team. A core ZFS developer, FreeBSD contributor, and co-author of FreeBSD Mastery: ZFS, Allan is a community go-to person for ZFS and open source through and through. He enjoys spending his time improving ZFS, advancing FreeBSD, and making open source code better.
Learn about Klara
Dr. Dan van der Ster is the CTO at CLYSO with over two decades of experience in distributed infrastructure. Holding a PhD from the University of Victoria, he spent 15 years in CERN's IT Grid and Storage Group, building the computing and storage infrastructure behind the landmark discovery of the Higgs Boson particle. As a member of the Ceph Executive Council leading the open-source project, Dan specializes in enterprise storage and scalable private cloud and supercomputing infrastructures.