SQLite is all you need for durable workflows

SQLite is All You Need for Durable Workflows 2026-05-29 DBOS recently argued that Postgres is all you need for durable execution : if you already trust your database, you do not need a separate orchestration tier. I agree with the direction, and I think the idea can be pushed further. For a large class of durable systems, SQLite is all you need. The Durable Part Durable execution is often discussed as if it requires durable infrastructure. In many cases it does not. The durable part is the workflow state. The compute can stay cheap and disposable. That is a natural fit for Obelisk: workflow progress lives in an execution log, workflows replay from persisted history, and activities can be retried. What matters most is keeping the workflow state around and easy to inspect. Why SQLite Fits SQLite is appealing because it gives you transactional durable state without introducing a separate database service. There is no network hop, no extra control plane, and no new operational surface area just to keep workflow progress safe. For many systems, a local database file is exactly the right level of machinery. Litestream Makes It Portable The obvious concern is what to do with those SQLite files once experiments start to accumulate. That is where Litestream helps. It can stream SQLite changes asynchronously to S3-compatible object storage. That gives you a simple way to keep working state close to the runtime while still copying databases out for backup, migration, and inspection. The caveat is that Litestream replication is asynchronous. A restore can miss the newest local writes if the SQLite volume disappears before they are copied. That is fine for many AI and experimentation workflows, but it is not the same thing as a highly available shared database. That still leads to a useful operating model: run an Obelisk server with a SQLite database, back it up with Litestream, and let an observer pull interesting databases when needed. The same file can be used for local repla