The suitability of Litestream for production disaster recovery is also an open question in my mind. I used 0.3.x for several years and when I tried to upgrade to the 0.5.x series there were runaway disk usage problems that would have caused downtime had they made it to prod. As far as I can tell these have not been entirely addressed, although recent bug reports suggest that they might be getting closer.

I want to love it, and I don't take open source projects like this for granted. But during my last production upgrade I chose to decommission Litestream in favor of a dumber, less granular solution using sqlite3_rsync and nightly backups because there is no point in using a backup system that is not rock solid.

Postgres also does not synchronously replicate for free. You can setup both to get a confirmation write if you require that durability.

> postgresql also does not synchronously replicate

By default. Generally your primary database is in a completely different failure category than a kubernetes node running an ephemeral workflow pod.

Either you have durable storage or you do not. SQLite and Postgres can both ensure local durability of commits. If you want distributed durability, you need to ship that data elsewhere. That is another Postgres node, object store, whatever that’s still an external dependency.

That’s about the local transaction, not replication. SQLite WAL also gives you strict durability.

  PRAGMA synchronous = full

"Durable workflows without the durability"

That's distributed workflows :)

S3 is strongly consistent, if you need it anyways you can just use s3 keys to deconflict and store the workflow state.

Yes, but directly using s3 as a key-value database is completely different from using SQLite + litestream.

try setting up replication/failover in postgres, it's much more work.

i mean it's durable as long as nothing crashes or litestream has a data corruption bug which only happens every other release...