Exploring Different Storage Options at Exoscale

Choosing the right storage is critical for cloud-native applications and scaling your infrastructure. In this blog, we’ll break down Exoscale’s storage options to help you find the best fit for your Kubernetes and Compute workloads.
Overview of Storage Options
We begin with a broad overview: these storage options are versatile and cater to a wide range of setups, from traditional compute instances to modern containerized Kubernetes environments.
Unlike self-managed installations, the Exoscale Managed Database Service takes care of all aspects of database administration, including automated backups, replication, and failover.
Choosing the Right Storage for Kubernetes Workloads
When running Kubernetes workloads, storage needs vary based on the nature of the application. Below, we discuss scenarios where each storage type excels and any limitations to consider.
Local NVMe Storage in Kubernetes
Local NVMe Storage provides unmatched performance for high-throughput applications. It is directly attached to the physical host running your virtual machine.
Exceptional performance; suitable for temporary data or caching.
- Kubernetes node cycling: Because nodes need to be updated or replaced from time to time, data on the local disk won’t survive node changes if not replicated or backed up elsewhere.
- No built-in durability: Local NVMe storage does not provide infrastructure-level durability. While RAID is used to mitigate hardware failures, it does not protect against VM termination or broader system failures. If you need data protection or high availability, your application or database must replicate data.
Another use case is distributed databases like Yugabyte, CockroachDB, or FoundationDB, which can leverage local NVMe performance while replicating data across nodes for durability.
Block Storage in Kubernetes
Block Storage is a natural fit for Kubernetes, especially for applications requiring persistent storage across node cycles. It supports scenarios where pods are rescheduled or nodes are replaced, ensuring data remains accessible.
- Seamless integration with Kubernetes via
PersistentVolumeClaim
s (PVCs) - Data durability across node lifecycles
- Ideal for stateful applications like content management systems (CMS) or application logs or simple databases
- Access-mode is ReadWriteOnce, meaning only a single node can mount a given volume at a time.
- Some advanced databases that require low-latency attached storage (e.g., local NVMe) may not perform optimally on remote block storage.
- While using StatefulSets with block storage is common, you should still plan carefully for backup, restore, and failover.
Generally speaking, having stateful workloads is more complex than managing stateless ones, so be prepared for additional planning.
Ideal for use cases like WordPress sites, application logs, or relational databases that require persistent storage.
Our documentation has simple examples.
Exoscale Managed Database Service (DBaaS)
Managed Databases offer high availability, automated backups, scaling, and failover, simplifying database management. Unlike self-managed installations, the Exoscale Managed Database Service takes care of all aspects of database administration, including automated backups, replication, and failover.
- Fully Managed: Exoscale handles all database operations, including provisioning, scaling, patching, and maintenance.
- High Availability: With automatic failover and replication, your database is always available, even in the event of a failure.
- Performance: Optimized for high-performance use cases, ensuring your database runs smoothly without the complexities of managing persistent storage manually.
- Multi-Zone: Use read replicas to also create replicas in other Exoscale zones. Increasing availability and performance.
- Scale any time: Change the plan any time - either up or down.
- High-availability database needs with automated backup and scaling
- Databases with strict performance requirements (e.g., transactional workloads)
- Applications that require ease of management and operational efficiency without the need to manage underlying storage or infrastructure.
Make sure to check out our detailed guide on deploying a fully stateless WordPress instance using Terraform and SKS. In this setup, static files are seamlessly stored in Object Storage, while the MySQL database connects effortlessly to a Managed Database with no setup required—just provide its URL and you’re ready to go!
You can find all supported databases here.
Object Storage in Kubernetes
Since Object Storage operates via an API, it’s best used directly within applications. However, Kubernetes can integrate it using AWS Mountpoint, enabling its use as Kubernetes Volumes.
Since Object Storage operates via an API, it’s best used directly within applications. Kubernetes can also integrate it via AWS Mountpoint to make buckets accessible as volumes.
Object Storage can support high read IOPS and scales well for read-heavy workloads.
However, it does not support in-place updates: writing changes requires uploading a new object. For many applications optimized for the S3 protocol (for example, storing large media files or analytics datasets),
this is not a problem and can deliver performance at scale.
Still, Object Storage must not be used for traditional databases requiring low-latency writes or frequent small updates.
Using Object Storage with AWS Mountpoint
Mountpoint is an open source S3 client by AWS that you can use to access the objects in your bucket like files on a filesystem and as Kubernetes Volumes. The ideal use case is for read-heavy applications that require large amounts of data (e.g. data lakes, machine learning training data, ETL).
Then install mountpoint (documentation):
kubectl apply -k "github.com/awslabs/mountpoint-s3-csi-driver/deploy/kubernetes/overlays/stable/"
If you apply the API key secret after installing it, you will have to restart all Mountpoint Pods.
After deployment you should see that a folder date was created with a filename with the current date!
Guidelines for Kubernetes Storage Selection
Storage Type | Best For | Avoid For |
---|---|---|
Local NVME | Caching, Temporary files, databases (with additional storage replication) | Persistant Workloads without data replication |
Block Storage | Stateful applications, logs, simple relational databases | Over 5k IOPS |
Managed Database | All supported databases with high performance and availability requirements | |
Object Storage | Static assets, large unstructured data, backups, shared files | Transactional or low-latency workload |
Conclusion
Whether you’re looking for ultra-fast Local NVMe Storage, scalable Block Storage, reliable Object Storage, or the simplicity of Managed Databases, Exoscale has the right solution for you.
Need help choosing the best option for your workloads? Feel free to reach out to our sales team at sales@exoscale.com or contact me directly at denis.arnst@exoscale.com — I’m happy to assist!