A blog post argues SQLite is enough for most durable workflows

A post on the Obelisk blog argues that for a large class of durable systems, SQLite is all you need — a step beyond the recent argument from DBOS that Postgres is all you need for durable execution. The author agrees with that direction: if you already trust your database, a separate orchestration tier is unnecessary. The post was published on 29 May 2026.

The durable part is the state, not the infrastructure

Durable execution is often discussed as if it required durable infrastructure. In many cases it does not: what has to survive is the workflow state, while the compute can stay cheap and disposable. That fits Obelisk’s model, where workflow progress lives in an execution log, workflows replay from persisted history, and activities can be retried. What matters most is keeping that state around and easy to inspect.

No network hop, no extra control plane

SQLite is appealing precisely because it provides transactional durable state without introducing a separate database service. There is no network hop, no additional control plane, and no new operational surface just to keep workflow progress safe. For many systems, a local database file is the right level of machinery.

Litestream makes the file portable

The obvious concern is what to do with those SQLite files once experiments start to accumulate. Litestream addresses it by streaming SQLite changes asynchronously to S3-compatible object storage, so working state stays close to the runtime while databases are copied out for backup, migration and inspection. The caveat is that replication is asynchronous: a restore can miss the newest local writes if the volume disappears before they are copied. That is acceptable for many AI and experimentation workflows, but it is not the same as a highly available shared database.

A good default for agents, with Postgres still in reach

The argument is aimed at AI agents and AI-generated workflows, which tend to be bursty and experimental and are easier to reason about when each agent or tenant has a small, self-contained unit of state. A fleet of tiny servers in micro VMs or containers, each with its own SQLite database and object storage backup, is often simpler, cheaper and better isolated than one large always-on shared system. Obelisk also supports Postgres, which the author calls the right choice when higher availability, broader shared scalability or a different durability model is needed. Many workflow systems do not need that on day one, the post concludes, and should not start with more infrastructure than their state actually demands.