SQLite is all you need for durable workflows — until it isn't

What happened

Obelisk, a workflow engine project, published a piece arguing that SQLite is sufficient as the durable backend for a Temporal-style execution engine — and Hacker News voted it to 585 points. The claim is narrow and specific: you do not need Cassandra, you do not need a sharded Postgres cluster, you do not need a separate history service. A single SQLite file in WAL mode, fsync'd on commit, will durably persist workflow state, event histories, timers, and signals for the workloads most teams actually run.

The argument rests on a few measured observations. Workflow state per execution is small — typically kilobytes of JSON-encoded event history. Writes dominate reads, and they are append-mostly. The hot path is a single worker polling for its next task, not a fan-out query across millions of rows. SQLite in WAL mode handles tens of thousands of writes per second on a laptop SSD, which exceeds the throughput of nearly every internal workflow system in production.

Obelisk implements this concretely: workflow events are appended to a single table, timers live in an indexed `due_at` column scanned every few seconds, and the entire engine — scheduler, executor, history — runs in one process against one file. No Kafka. No Cassandra. No three-tier deployment diagram.

Why it matters

The durable-workflow space has been dominated by Temporal's architectural blueprint: a stateless frontend, a sharded history service, persistent queues, and a heavyweight backing store. Temporal Cloud exists in large part because running that stack yourself is genuinely painful — you are operating a distributed database before you have written a single line of business logic. Cadence, Restate, and Inngest all carry variations of the same operational weight.

The Obelisk post is part of a broader pattern. SQLite-as-default has gone from contrarian take to mainstream architecture in roughly three years — Litestream, rqlite, Turso, Cloudflare D1, and now durable execution all bet on the same thesis: most workloads do not need a distributed database, they need a fast local one with good backups. Fly.io's LiteFS, Tigris, and the entire "local-first" movement compound the trend. The technical argument is consistent: NVMe is fast, B-trees haven't changed, and the network is still the bottleneck for most queries.

What makes durable workflows a particularly clean fit is the access pattern. A workflow execution is owned by exactly one worker at a time. There is no need for distributed locking, no read-replica fanout, no cross-shard transactions. The whole job is: append an event, advance the state machine, schedule the next timer. SQLite does this in microseconds. Temporal's architectural complexity exists to serve multi-tenant SaaS at hyperscale; Obelisk's bet is that 95% of teams running Temporal are paying that complexity tax for scale they will never reach.

The HN comments split predictably. The Temporal camp pointed out — correctly — that you lose horizontal write scaling, that backup and PITR become your responsibility, that a corrupted file means a corrupted system, and that multi-region active-active is off the table. The SQLite camp pointed out — also correctly — that those concerns apply to maybe 5% of real deployments, and the other 95% are running a Cassandra cluster to orchestrate their nightly cron jobs.

What this means for your stack

If you are evaluating durable workflow engines right now, the decision tree just got simpler. Start with SQLite-backed (Obelisk, or a roll-your-own on top of `better-sqlite3` / `rusqlite`) unless you have a concrete reason not to — and "we might need scale someday" is not a concrete reason. Migrate to Temporal or Restate when you hit one of the real ceilings: sustained write rates above ~5k workflows/sec, multi-region active-active requirements, or regulatory constraints that demand a managed audit trail.

The operational implications are worth pricing in. Backup strategy matters more, not less — Litestream streaming to S3 gives you point-in-time recovery, but you need to actually configure it. A SQLite-backed engine is a single point of failure by design; that is the tradeoff you are accepting in exchange for the radical simplicity. Plan for it: warm standby with WAL replication, tested restore procedures, and clear SLOs on recovery time. The systems that quietly break in this architecture are the ones where teams treated "it's just a file" as license to skip the boring durability work.

For side projects, internal tooling, and the long tail of "we need to retry this API call with exponential backoff and survive a restart" — which is most of what workflow engines actually do — the answer is now obviously SQLite. The Temporal stack was always overkill for those use cases; it just lacked a credible single-binary alternative. Obelisk is one of several projects closing that gap.

Looking ahead

The interesting question is not whether SQLite can back a workflow engine — it clearly can — but what happens when the SQLite-default thesis collides with the second machine you need to add. The current generation of projects has thoughtful answers (LiteFS, embedded replicas, async followers) but none of them are as boring or as battle-tested as Postgres streaming replication. Expect the next 18 months to be about whether the SQLite ecosystem can produce a genuinely production-grade multi-node story, or whether "SQLite is all you need" quietly becomes "SQLite plus a real database when you grow up." The teams betting on Obelisk today are betting on the former.