Best practices
Local versus remote SSDs
Kubernetes provides you with an option of employing remote disks using dynamic provisioning or local storage which has to be preprovisioned.
Local storage provides great performance, but the data is not replicated and can be lost if the node fails. This option is ideal for databases, such as YugabyteDB, that manage their own replication and can guarantee high availability (HA).
Remote storage has slightly lower performance but the data is resilient to failures. This type of storage is absolutely essential for databases that do not offer HA (for example, traditional relational databases, such as PostgreSQL and MySQL).
The following table summarizes the features and when to use local or remote storage:
| Feature | Local SSD storage | Remote SSD storage |
|---|---|---|
| Provision large disk capacity per node | Depends on cloud-provider | Yes |
| Ideal deployment strategy with YugabyteDB | Use for latency sensitive apps Add remote storage to increase capacity / cost-efficient tiering |
Use for large disk capacity per node |
| Disk storage resilient to failures | No | Yes |
| Performance - latency | Lower | Higher |
| Performance - throughput | Higher | Lower |
| Typical cost characteristics | Lower | Higher |
| Kubernetes provisioning scheme | Pre-provisioned | Dynamic provisioning |
It is generally preferable to use local storage where possible for higher performance and lower costs. For information on how to deploy YugabyteDB on Kubernetes using local SSDs, see Single-zone GKE.