Typical Cloud‑Native Storage Solutions for Stateful Applications and Their Performance Comparison

Cloud‑native has become the preferred architecture for modern applications, shifting the responsibility for agility, scalability, reliability, and high availability to infrastructure software and operations teams, while developers focus on business logic.

Over the past three decades, deployment models have evolved from physical servers to virtual machines, large‑scale clouds, and now Kubernetes platforms, increasing the demand for storage systems that not only deliver performance, stability, and reliability but also support rapid provisioning, scaling, and automated operations.

Three main storage approaches are examined: local disks —offering the shortest I/O path and high performance but lacking node‑level high availability and scalability; centralized storage —providing shared access and high availability but suffering from performance bottlenecks and limited agility in cloud‑native scenarios; and distributed storage —offering horizontal scalability and superior high‑availability characteristics, yet often facing implementation complexity and inconsistent production‑grade performance.

Stateful cloud‑native applications, especially databases, have distinct storage requirements: OLTP (transactional) databases such as MySQL or PostgreSQL demand low latency, high bandwidth, and rapid scaling, typically using block storage with snapshot and cloning features; OLAP (analytical) databases prioritize cost‑effective capacity and can tolerate higher latency, often relying on erasure‑coded object storage accessed via S3‑compatible interfaces.

Multi‑cloud deployments introduce additional challenges because public and private clouds differ in APIs, performance, and operational models; cloud‑native storage aims to provide a uniform, container‑friendly, declarative interface that works consistently across these environments.

Key characteristics of cloud‑native storage include minimal hardware or kernel dependencies, efficient resource usage to avoid excessive CPU/memory consumption, support for declarative management (including automated scaling and upgrades), and seamless integration with the broader cloud‑native ecosystem (monitoring, alerting, logging).

When selecting a cloud‑native storage solution, practitioners should consider reducing environment dependencies, avoiding resource over‑consumption, enabling declarative operations, and ensuring compatibility with existing cloud‑native tooling.

A performance benchmark was conducted on four cloud‑native storage systems—IOMesh, Longhorn, Portworx, and OpenEBS—using a three‑node cluster (each with SSDs, HDDs, and 10 GbE NICs) and a MySQL workload driven by sysbench‑tpcc. The results show that IOMesh consistently outperforms the others in TPS, QPS, and P95 latency stability, demonstrating its suitability for core production workloads.

In conclusion, as more workloads adopt cloud‑native architectures, storage systems must evolve to meet new agility, scalability, and reliability demands; cloud‑native databases and storage solutions are expected to become increasingly prevalent in data centers.