Skip to content

Use Cases

This page is a gut-check. It does not list every workload that might fit MeshStor — it lists the patterns where MeshStor is clearly the right answer, the patterns where it is clearly not, and the patterns where MeshStor will eventually fit but does not yet.

For the substantive head-to-head against named alternatives, see Comparison. For the maturity story, see Project Status.

Use MeshStor when…

  • You need replicated block storage with the lowest possible latency. AI jobs waste 30–40% of GPU time waiting on I/O from storage or vector database rather than computing. MeshStor's kernel-level data path keeps both fsync and read latency low — any application, AI model, or vector database that wants replicated block storage benefits, and latency-sensitive workloads benefit most.
  • You want the simplest possible storage control plane. MeshStor runs as a single binary in your existing cluster. There is no etcd cluster to operate, no separate storage cluster, no additional agents.
  • You need replicated block storage for stateful workloads that don't replicate themselves. Databases without built-in clustering, file servers, message queues with single-node persistence — these are the canonical fit. MeshStor was designed by engineers who spent a decade running databases on Kubernetes in production, and the driver's reliability, fsync-latency, and recovery targets were chosen with those workloads in mind from day one. Any application wanting replicated block storage benefits from that rigor; workloads with strict durability expectations are safe.
  • You want local-storage performance and simplicity but with operational features that pure local CSIs cannot provide. Use replicaCount=1. The volume goes through the same data path as a replicated volume but only writes to one local underlying partition. You get pod rescheduling across nodes without losing data, automatic data relocation on planned node-drain, and (when shipped) cross-node snapshots — none of which are possible with TopoLVM, OpenEBS LocalPV-LVM, or local-path-provisioner.
  • You want local-storage with extremely low latency. Evaluate replicaCount=1 MeshStor on your specific workload — see the local-storage section of Comparison.

Don't use MeshStor when…

Don't use ever

  • You need real ReadWriteMany. MeshStor is a block storage driver. RWX is not on the roadmap and not under consideration. Use a file storage system (NFS, CephFS, an SMB server) for shared filesystems.
  • You need file or object storage. MeshStor only provides block volumes. For object storage use MinIO, Rook-Ceph RGW, or a cloud object store. For file storage use the same NFS/CephFS/SMB options as above.
  • You need multi-cluster active-active replication. MeshStor replicates within a single Kubernetes cluster. Cross-cluster replication is not on the roadmap.

Don't use yet (feature is on the roadmap)

  • You need snapshots or clones. They are planned for the roadmap. The performance penalty cost is paid once at snapshot creation time, not on every write — see Project Status.
  • You need raw block volumes. Planned for the roadmap. MeshStor currently supports XFS-formatted volumes only.
  • You need an Ext4 filesystem. Planned for the roadmap. MeshStor currently supports XFS only.
  • You need encryption at rest. Planned for paid customers.
  • You need KubeVirt live migration support. Planned for paid customers. Implemented as a deliberately fake ReadWriteMany — a controlled multi-attach shim that lets two pods on different nodes hold the same volume during the live-migration window only.
  • You need per-volume Quality of Service (IOPS or bandwidth limits). Planned for paid customers. Useful when co-tenanting noisy workloads on the same NVMe drives or NVMe-oF links.

Use a different category entirely

  • You're on managed-cloud Kubernetes (EKS, GKE, AKS) with EBS / Persistent Disk available. Use the cloud's native CSI driver. MeshStor's value proposition (kernel-grade replicated block on bare metal) does not apply.

What's Next