The ephemeral-pod-plus-restore-on-init pattern works right up until it doesn't, and the failure is quiet, so "no issues so far" is unfortunately consistent with both a correct setup and one that is going to bite.

Litestream assumes a single writer. It replicates one SQLite file's WAL to object storage; it is not multi-master. If you ever end up with two pods writing, you get two databases diverging and replicating over the top of each other, and nothing errors. You find out when you notice writes going missing.

The two ways people get there without meaning to:

- replicas gets bumped above 1, sometimes by an HPA nobody remembered was on. - RollingUpdate. It briefly runs old and new pods together, which is enough. Recreate avoids it at the cost of a restart gap.

The other thing worth knowing is that replication is asynchronous with a default sync interval of one second, so a hard pod kill can lose whatever was written since the last sync. Fine for a lot of workloads. Not fine if the thing has quietly become a durable transaction log for something that matters.

LiteFS was the answer for genuinely multi-node, though I would check its current maintenance status before building on it.

On Kubernetes, for apps using SQLite, maxReplicas is set to 1 and OpenRun uses the Recreate update strategy. This ensures at most one pod is active (requests are queued until the new pod is healthy). There should never be more than one pod accessing the SQLite database.