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

When setting up a repeatable single‑node k3s development environment, the choice of datastore influences both the time to reach a usable cluster and the effort required to restore a known state after a teardown. The embedded SQLite store starts instantly and needs no external service, but creating a consistent backup requires stopping the server or migrating to etcd first. An external etcd endpoint adds modest network latency yet provides built‑in snapshot tools and supports future horizontal scaling.

Given these trade‑offs, which datastore yields the lowest overall cycle time for a developer who frequently destroys and recreates clusters while also needing reliable state restoration? Is the additional latency of etcd perceptible during typical local dev workloads such as running a few NGINX pods? Does the operational overhead of running a separate etcd node outweigh the benefit of live snapshots for a single‑node dev setup?