Embedded SQLite vs External etcd: Simplicity vs Scalability for Edge Deployments

Goal

Determine the optimal data‑store strategy for a low‑resource edge node that must balance minimal configuration with resilience to data corruption.

Constraints

• k3s offers two documented modes: embedded SQLite (default) and external etcd.
• SQLite stores all API objects in a single local file (k3s.db) and the process terminates if the file becomes corrupted; there is no automatic repair.
• External etcd requires a pre‑provisioned cluster, enabling high availability but adding operational complexity.

Uncertainty

When an edge deployment uses SQLite, the lack of self‑repair may increase downtime. It is unclear whether proactive detection or manual migration to etcd can mitigate this risk, or if additional tooling is required.

Questions

• What mechanisms can detect SQLite corruption before k3s exits, and how can they be integrated into a single‑node workflow?
• Is there a recommended recovery strategy that avoids manual deletion and recreation of k3s.db while preserving cluster state?
• Under what performance or resource constraints does the trade‑off favor switching to external etcd for an edge node?