Argues that modern SQLite's WAL mode, fsync-on-commit durability, and single-writer architecture deliver the same correctness guarantees as Temporal without the operational tax of a Postgres cluster, message bus, and worker pool. Cites Obelisk's benchmark of ~12,000 state transitions/sec at p99 <3ms on a single NVMe node as evidence that 90% of durable-execution workloads fit comfortably inside one SQLite file.
Acknowledges in the post itself that SQLite's single-writer thread is the architectural trade-off: it eliminates distributed consensus problems at small scale but forces a return to sharding and replication once workloads exceed what one node can handle. This concedes that Temporal-class platforms remain justified for the high-scale 10% of use cases.
Frames Temporal's seven-service reference deployment — four of which need dedicated operational expertise — as evidence that the category has spent five years convincing engineers that workflow orchestration requires platform-grade infrastructure when in fact the implementation tax often outweighs the exactly-once and replay benefits for typical workloads.
A post titled *SQLite is all you need for durable workflows* hit 437 points on Hacker News this week, written by the team behind Obelisk — an open-source durable execution runtime that ships as a single binary with SQLite embedded. The argument is blunt: the orchestration tier that Temporal, Restate, and Inngest sell you — a Postgres cluster, a message bus, a scheduler, a worker pool — is overkill for the workloads most engineers actually run.
The technical claim rests on three properties of modern SQLite. WAL mode (write-ahead logging, enabled by default since 3.7) gives you concurrent readers alongside a single writer without blocking. `fsync` on commit gives you the same durability guarantee Postgres does on the same hardware. And a single writer thread — which sounds like a limitation — actually eliminates the entire class of distributed-consensus problems that Temporal solves with Cassandra or CockroachDB underneath.
Obelisk's benchmark shows ~12,000 workflow state transitions per second on a single NVMe-backed node, with p99 latency under 3ms — numbers that would require a 3-node Temporal cluster and a dedicated DBA to match. The catch, which the post acknowledges, is that you get one writer. Scale past that and you're back to sharding, replication, and the distributed problems you were trying to avoid.
The durable execution category — Temporal, Restate, Inngest, DBOS, Cadence — has spent five years convincing engineers that workflow orchestration is a *platform* problem requiring dedicated infrastructure. The pitch is real: exactly-once semantics, automatic retries, deterministic replay, time-travel debugging. The implementation tax is also real: Temporal's reference deployment is seven services, four of which need their own operational expertise.
Obelisk's argument is that 90% of teams reaching for durable execution have workloads that fit comfortably inside a single SQLite file, and the other 10% should be honest about needing a platform team. This isn't a new observation — Litestream, rqlite, and Cloudflare's Durable Objects have been making variants of it for years — but it lands differently when applied to workflows specifically, because workflow state is the canonical case where people *think* they need distributed consensus.
The HN comments split predictably. The Temporal camp argues that single-writer is a ceiling you'll hit unexpectedly, and that the cost of migrating off SQLite later exceeds the cost of running Temporal from day one. The pragmatist camp counters that you will not hit 10k workflow events/sec, and engineers consistently underestimate how much complexity they're buying to handle scale they'll never reach. One commenter, a former Uber engineer who worked on Cadence (Temporal's predecessor), put it directly: *"We built Cadence to handle Uber's scale. If you're not Uber, you probably want something smaller."*
The cost comparison is stark. A production Temporal Cloud deployment for moderate workloads runs $2-5k/month before you count the engineering time to wire it in. An Obelisk-style single-node deployment runs whatever a t4g.medium costs you — about $30/month — and the operational burden is "back up the SQLite file." For a startup with twelve background jobs that need to be reliable, the math isn't close.
What's genuinely interesting is the consistency story. SQLite gives you serializable isolation by default — the strongest guarantee in the SQL spec. Postgres defaults to read-committed and most teams never upgrade it. Distributed workflow engines built on eventually-consistent storage have to layer correctness on top with vector clocks, version vectors, or consensus protocols. SQLite just... doesn't have the problem, because there's one writer and one log.
If you're evaluating durable execution right now, the honest decision framework is: what's your sustained write rate, and do you need multi-region? Under 10k events/sec, single region, fewer than ten engineers — SQLite-based options (Obelisk, DBOS's embedded mode, or a hand-rolled solution on Litestream) will be cheaper, simpler, and more debuggable than Temporal. Above that, or with hard multi-region requirements, the distributed engines earn their complexity.
The migration path matters more than the initial choice. Obelisk's workflow API is intentionally close to Temporal's — durable functions, activities, signals, queries — so a team that outgrows it can port to Temporal without rewriting business logic. That's the right product decision: don't lock users into your scaling ceiling. If you're greenfield, starting with the SQLite version and migrating if you hit the wall is strictly cheaper than running Temporal speculatively.
The operational story also flips the usual calculus. With Temporal you have an orchestrator, a database, and worker pools, each with their own failure modes. With a single-file SQLite workflow engine, your disaster recovery is `cp workflows.db backup.db` and your monitoring is `df -h`. That's not a smaller problem to manage — it's a categorically different problem. Engineers underestimate how much of their on-call burden comes from operating the systems they chose to handle scale they don't have.
The broader pattern here — rich single-node systems beating distributed systems for the median workload — keeps repeating. DuckDB is doing it to Spark for analytics under a terabyte. Bun is doing it to multi-runtime JS toolchains. Now SQLite is doing it to Temporal for workflows. The common thread: hardware got fast enough that the distributed-systems tax stopped being free, and the median team's scale stopped justifying it. Expect the next wave of "all you need is X" posts to keep landing, because the math keeps working out the same way.
The cycle of expertise :- what is X, I just do Y- wow I can see so many limits of Y, now I do X- I use X for literally everything- now that I properly understand the limits of Y but also the heavy constraints of X ... maybe Y is enough- I use Y for literally everythingrinse & repeat. The thing i
I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes,
I've replaced all of these with Go + SQLite:1. Intercom 2. Zendesk 3. Email marketing 4. Kanban 5. Todo 6. Our billing stack 7. Our issue tracker 8. Our forum 9. Uptime monitor 10. PagerDuty (clone)I have dozens of products I sell, so I thought: why not build everything ourselves?All of these r
SQLite is surprisingly performant for single node applications even when comparing to Postgres. Postgres consumes a lot more memory and requires IO to hop through IPC whereas you can keep everything in process in SQLite with a shared connection pool.I've been testing different storage engines f
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I started setting up my workflows using Temporal. It deploys as relatively light weight local app. For an isolated local installation it uses SQLite. It makes the process of dealing with API retries and organizing workflows and tasks really simple. I recommend giving it a try. It is, philosophically