Choosing a distributed storage solution for Kubernetes is one of the most consequential infrastructure decisions you'll make. Get it wrong and you're dealing with data loss, OOM-killed storage daemons, or a migration that takes weeks.
This post compares Longhorn and Rook/Ceph from the perspective of someone who has run both in production.
TL;DR
Use Longhorn if:
- ›You have fewer than 20 nodes
- ›You want block storage only (RWO volumes)
- ›You want S3 backup without additional tooling
- ›Your team has limited Ceph expertise
Use Rook/Ceph if:
- ›You need shared filesystems (RWX via CephFS)
- ›You need S3-compatible object storage (Ceph RGW)
- ›You have 10+ storage nodes and performance is critical
- ›You have a team with Ceph experience
Setup Complexity
Longhorn installs in about 5 minutes:
helm repo add longhorn https://charts.longhorn.io
helm install longhorn longhorn/longhorn \
--namespace longhorn-system --create-namespace
It comes with a web UI at /longhorn-ui where you can manage volumes, snapshots, and backups visually.
Rook/Ceph requires significantly more configuration. You need to define:
- ›
CephClusterresource (which nodes, which disks) - ›
StorageClassfor each pool type - ›Mon/OSD/MGR placement rules
A minimal Rook Ceph cluster requires at minimum 3 OSD nodes with dedicated disks, and proper CPU/RAM allocation for the Ceph daemons.
Resource Usage
This is where Longhorn wins decisively for small clusters:
| Component | Longhorn | Rook/Ceph |
|---|---|---|
| Per storage node RAM | ~300 MB | 1–2 GB |
| Manager pod | ~100 MB | ~500 MB (mgr + mon) |
| UI | Built-in (lightweight) | Ceph Dashboard (heavy) |
| Disk overhead | Thin provisioned | Thin provisioned |
On a Hetzner cx43 (8vCPU/16GB) worker node, Longhorn uses ~2% of available RAM. Ceph would use 10–15%.
Performance
For typical Kubernetes workloads (databases, stateful apps), Longhorn performs adequately. Longhorn uses iSCSI/NVMe-oF to replicate volumes synchronously — writes go to all replicas before acknowledging.
Rook/Ceph outperforms Longhorn on:
- ›Large-scale sequential writes (Ceph RADOS is purpose-built)
- ›Multi-attach RWX volumes (CephFS)
- ›Object storage throughput (Ceph RGW)
For a 5-node Kubernetes cluster running PostgreSQL, Redis, and a few stateful apps, the performance difference is not meaningful. You'd need specific benchmarks to justify Ceph's operational cost.
Backup Strategy
Longhorn has built-in S3 backup — configure a backup target and set up recurring jobs via CRD or the UI. No additional tooling needed.
Ceph relies on Velero for cluster-level backup. Velero is a solid tool, but it's an additional component to install, configure, and monitor.
Use the Longhorn S3 Backup Config Generator to set up Longhorn backups to Hetzner Object Storage.
Storage Calculator
Use the Longhorn Storage Calculator to plan your storage requirements including replica overhead, snapshot retention, and S3 backup sizing.
When to Start with Longhorn and Migrate Later
Start with Longhorn. If you later need:
- ›RWX volumes → install Ceph alongside Longhorn, use CephFS for shared volumes
- ›Object storage → use MinIO alongside Longhorn (simpler than Ceph RGW)
- ›
20 nodes with heavy I/O → evaluate full Ceph migration
Migration from Longhorn to Ceph is possible via Velero backup/restore, but it's a maintenance window operation. Plan it carefully.