Executive Summary
Usage charts measure what ships with the platform, not what teams choose. The top of the CNCF survey is a dependency. The number behind it is the story, because that is where stateful workloads actually land.
etcd takes the top slot because Kubernetes needs it to hold cluster state, and every cluster has one. It is a key-value store. Nobody points a database or a persistent volume at it. Longhorn is the project teams install themselves, CNCF incubating and SUSE-backed, built as the persistent storage layer for Kubernetes. Each volume gets a controller and replicas across nodes with synchronous replication, so a node failure does not lose data. It installs with one command or a Helm chart and ships a web UI, which matters for teams without a storage specialist. Two forces push toward it, the VMware migration moving data onto Kubernetes and AI workloads needing somewhere to keep checkpoints. Watch the gap between dependency and choice.
etcd wins because it comes with the cluster
The top slot in the latest CNCF annual survey goes to etcd, and that should not surprise anyone. etcd is the key-value store that Kubernetes uses to keep the state of the cluster. It ships with Kubernetes. Every cluster has one. When the survey asks which projects organizations run, etcd is near the top because it is not a choice, it is a dependency.
The interesting number is the one that sits right behind it. Among the storage projects that Kubernetes users actually deploy themselves, Longhorn is the name that keeps showing up. It is CNCF incubating, it is SUSE-backed, and it is built to be the persistent storage layer for Kubernetes. In the survey’s project rankings, Longhorn is the most-used Kubernetes-native storage project after etcd, and most of the gap between the two is a quirk of how the question is asked.
What a key-value store is not
etcd answers a narrow question. It stores the cluster’s configuration and state so the control plane can agree on what is running. It is not a place to put application data. You would never point a database, a file system, or a container’s persistent volume at etcd. It is small, fast, and deeply boring on purpose.
That is the whole point of the distinction. When you measure storage adoption on Kubernetes, you are really measuring something else. You are measuring where the stateful workloads live. Databases, message queues, analytics engines, model checkpoints. Those all need block or file storage that survives a pod restart. Longhorn exists for exactly that.
The distinction also matters when you read the survey. A project that ships with the platform will always top a usage chart. A project that has to be installed, configured, and maintained to carry real data is doing more work to earn its place. Longhorn is that second kind of project, and it still sits near the top.
Why Longhorn keeps winning the practical race
Longhorn is distributed block storage built for Kubernetes. It uses the cluster itself to orchestrate storage. Each volume gets a controller and replicas spread across nodes, with synchronous replication so a node failure does not lose data. It installs with a single command or a Helm chart, and it has a web UI that makes it approachable for teams that do not have a storage specialist.
That last point is the quiet advantage. Rook-Ceph is powerful but it wraps Ceph, which has a learning curve. OpenEBS is simpler but it has never had the same pull. Longhorn sits in the middle and it is the one that most often gets deployed by a platform team that just needs block storage to work without becoming a second job.
The numbers track that. Longhorn is consistently among the most-deployed Kubernetes-native storage projects in the CNCF landscape, and it has grown alongside Kubernetes itself. More clusters means more stateful workloads, and more stateful workloads means more Longhorn.
That growth is not accidental. Two forces are pushing in the same direction. The migration wave off VMware is moving workloads to Kubernetes-based platforms, and those workloads carry data. At the same time, AI workloads on Kubernetes need somewhere to store model artifacts, checkpoints, and vector data. Both steer platform teams toward a storage layer that works without a separate team to run it.
The takeaway for platform teams. If you are running Kubernetes in production and you have not yet picked a storage layer, the survey is a nudge in a specific direction. The storage problem on Kubernetes is not solved by the control plane. It is solved by the project that makes persistent volumes boring.
etcd wins the headline because it comes free with every cluster. But the project that actually carries the data, and the one that teams reach for when they need storage that scales with the cluster, is the one worth watching. It is why a Kubernetes-native storage project now sits at the top of its category, and why the number behind the headline matters more than the headline.
Every announced commitment in this space is tracked with its source in our AI data centre power commitments record.
Related reading. Kubernetes Storage Carries the Data and Gets the Least Coverage. Karmada Just Graduated. Multi-Cluster Kubernetes Is Now a Solved Problem, Sort Of.. Your Kubernetes Bill Is an Architecture Problem, Not a FinOps Problem. The 2026 State of Enterprise Infrastructure.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data centre economics. No vendor spin.
[…] Read the full breakdown. […]