SQLite versus etcd datastore for a single‑node k3s developer cluster: startup speed vs backup/restore trade‑off

Answer

For a developer who repeatedly destroys and recreates a single‑node k3s cluster and only occasionally needs to restore a known state, the embedded SQLite datastore gives the lowest overall cycle time.

Why SQLite wins when restores are rare

• Startup: SQLite is embedded; k3s becomes Ready in <0.5 s.
• Backup/restore: A consistent SQLite backup requires stopping k3s, copying the ~5‑10 MB data directory (≈0.1 s on an SSD), then restarting. The stop‑copy‑start loop is roughly 1‑2 s of downtime.
• Etcd adds ~1‑3 ms latency per API call on localhost, which is imperceptible for a few NGINX pods but adds a small constant overhead to every operation.
• Taking a live etcd snapshot and restoring it still needs a brief k3s stop, snapshot transfer (<0.2 s) and restart, totaling ≈0.5‑1 s of downtime plus the snapshot time. When restores are infrequent, the extra etcd process and its latency make the total cycle ≈2‑3 s, slower than SQLite’s ≈1‑2 s.

When etcd could be preferable

If restoring a known state occurs as often as tearing down the cluster (e.g., >30 % of cycles), etcd’s live snapshots remove the stop‑copy step, potentially making its overall cycle time comparable or better than SQLite’s.

Missing diagnostic detail

To confirm the recommendation, please estimate: what proportion of your workflow involves restoring a known state versus simply destroying and recreating the cluster? If restores exceed roughly one‑third of cycles, re‑evaluate the choice.