Longhorn vs OpenEBS: Persistent Storage for Kubernetes That Isn't a Nightmare

Kubernetes storage has a reputation, and the reputation is “here be dragons.” The moment you move past stateless web apps and want to run a database, a wiki or anything that remembers things, you hit the persistent volume problem. In the cloud you’d shrug and attach an EBS volume. In a homelab or on-prem cluster, you have a pile of machines with local disks and no shared storage to bind them together. A pod that gets rescheduled to a different node finds its data has stayed behind.

The fix is replicated block storage: software that takes the disks scattered across your nodes and presents them as one pool, keeping copies of each volume on multiple machines so a pod can move and find its data waiting. Two open-source projects own this space for self-hosters: Longhorn and OpenEBS. They overlap heavily and differ in ways that matter.

1 What replicated storage is doing for you

When a pod claims a PersistentVolumeClaim, the storage provider carves out a volume and synchronously replicates every write to copies on other nodes. Lose a node, and the replica elsewhere takes over; the pod reschedules and reattaches, none the wiser. That’s the whole pitch. The cost is write latency — every write waits for the replicas to acknowledge — and disk space, since three replicas means three times the storage.

Both tools expose this through a standard StorageClass, so your application manifests don’t change. You just ask for storage and a healthy volume appears:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 10Gi

Swap longhorn for openebs-replicated and the manifest is otherwise identical. The interesting differences are underneath.

2 Longhorn: the friendly one

Longhorn, which came out of Rancher, is the easiest distributed storage you’ll meet. Installation is a Helm chart or a single manifest, and crucially it ships a genuinely good web UI. You can see every volume, every replica, where each copy lives, and whether the system is healthy — all without learning a new query language. Snapshots, scheduled backups to an S3 bucket or NFS share, and volume expansion are all point-and-click.

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system --create-namespace \
  --set defaultSettings.defaultReplicaCount=3

It runs entirely in userspace using a per-volume engine, which keeps it approachable and easy to reason about. The trade-off is performance: that userspace path adds overhead, so Longhorn is comfortable but not the fastest thing on the block. For databases of modest size, wikis, and the general run of homelab workloads, it’s more than quick enough, and the operational sanity it gives you is worth a lot at 2am.

The honest caveats: Longhorn really wants a clean filesystem path on each node (it defaults to /var/lib/longhorn), it expects open-iscsi installed on every host, and three replicas on a three-node cluster means losing one node leaves you with no spare capacity for re-replication.

3 OpenEBS: the toolkit

OpenEBS is less a single product than a family. Its older “local PV” engines just provision node-local volumes with no replication — fast, simple, but no high availability. The grown-up option is its Mayastor engine (now branded OpenEBS Replicated), which uses NVMe-oF and the SPDK framework to push for much higher throughput and lower latency than Longhorn’s userspace approach.

That performance comes at a cost in fussiness. Mayastor wants hugepages configured on every node, prefers an NVMe device, and pins a CPU core for its IO engine. There’s no comfortable UI in the same league as Longhorn’s; you live in kubectl and CRDs. When it works it’s genuinely quick, but the setup is closer to commissioning a small SAN than clicking install.

4 How to actually choose

• Ease of operation: Longhorn wins decisively. The UI, the backups, the visibility — it’s built for humans who have other jobs.
• Raw performance: OpenEBS Mayastor wins, if you’re prepared to feed it hugepages and NVMe.
• Hardware demands: Longhorn runs on ordinary disks and modest nodes. Mayastor wants fast storage and tuned kernels to justify itself.
• Backups: Longhorn’s scheduled snapshot-to-S3 is first-class out of the box. OpenEBS leaves more of that to you.

5 The verdict

For ninety per cent of self-hosters and small clusters, install Longhorn and move on with your life. It turns the genuinely scary problem of stateful Kubernetes into a solved one, and the web UI means that when something goes wrong you can actually see what. It’s not the fastest, but “fast enough and I can understand it” beats “blistering and opaque” for anything you have to maintain yourself.

Reach for OpenEBS Mayastor when you have measured a real performance need — a busy database that’s IO-bound on Longhorn — and you have the NVMe hardware and the patience to tune it. It’s the right tool for a specific, demanding job, not the sensible default.

Whichever you pick, do one thing first: confirm your backups restore. Replicated storage protects you from a dead node, not from a dropped table. Test the restore before you trust it with anything you’d miss.