Best practices
Local vs remote SSDs
Kubernetes gives users the option of using remote disks using dynamic provisioning or local storage which has to be pre-provisioned.
Local storage gives great performance, but the data is not replicated, and can be lost if the node fails. This option is ideal for databases, like 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, like PostgreSQL and MySQL).
Below is a table that summarizes the features and when to use local or remote storage.
| 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 |
Thus, it is generally preferable to use local storage where possible for higher performance and lower costs. The GKE section shows how to deploy YugabyteDB on Kubernetes using local SSDs.