# SQLite 就够了（用来做持久化工作流）
2026 年 5 月 29 日的 HN 上，有人发了篇博客《SQLite is All You Need for Durable Workflows》，549 分，279 条评论。文章本身很短，真正长的是评论。
作者顺着 DBOS 那句"Postgres is all you need"往下推：很多 durable workflow 里，真正需要 durable 不是计算节点，而是 workflow state。计算可以便宜、短命、随时重启；状态只要能留下来、能 replay、能 inspect，就够了。所以他的方案很朴素：每个 workflow 的进度写进本地 SQLite 文件，再用 Litestream 异步复制到 S3。
他也没把话说死：Litestream 是异步的，机器在最新写入还没复制出去前消失，就可能丢最后一小段；要高可用、共享扩展，还是用 Postgres。
但 HN 不会放过标题里的"all you need"。
orf 第一个抓住这点：
> SQLite is not all you need, unless you're just experimenting don't actually care about durability, in which case you also need litestream + object storage.
有人补刀成一句："Durable workflows without the durability"。
还有人提到自己用 Litestream 的生产升级经历：0.3.x 用了几年，升到 0.5.x 时遇到 runaway disk usage，最后放弃 Litestream，改用更笨但更稳的 `sqlite3_rsync` 和 nightly backups。"因为备份系统不 rock solid 就没有意义。"
这一层争论把「durability」拆成了两件事。SQLite 可以保证本地 commit 的 durable——WAL、`PRAGMA synchronous = full` 都在那里。但如果你要的是机器死掉、盘消失、跨节点仍然不丢，那就是 distributed durability。0cf8612b2e1e 说得直白：Either you have durable storage or you do not. 想要分布式 durability，就得把数据送到别处，不管那个别处是另一个 Postgres node、object store，还是别的什么。
Postgres 默认也不是免费给你同步复制，只是它在这个方向上有更成熟的工具链。这篇文章最容易被误读的地方，是把「少一个数据库服务」听成「少一个外部依赖」。实际上 SQLite + Litestream + S3 仍然是一个系统，只是把数据库服务换成了文件、复制进程和对象存储。少掉的是控制平面和网络 hop，不是魔法。
Xcelerate 说自己刚好在做类似的事：
> I typically ask agents to design a DAG first based on a set of specifications and then execute it (each step stores something in a SQLite DB). Iteration is pretty simple then because I just ask for a tweak to one or two steps of the DAG, and then to re-run.
另一个人接得更简洁：every checkbox in this PLAN.md should be task in SQLite.
这个画面很具体：不是把 SQLite 当万能后端，而是把它当 agent 的工作台。Markdown 和 JSON 对人友好，但一旦状态开始增长、需要局部更新、需要查询某一行，agent 去 grep、jq、整文件读写，代价很快就变难看。给 agent 一个小数据库，等于给它一个可查询、可约束、可局部修改的记忆结构。
于是评论里慢慢从「SQLite vs Postgres」滑向另一个问题：很多时候大家想要的不是 SQLite，而是 SQL。
phamilton 说，他最喜欢 SQLite 的角度不是 SQL 语法，而是两件东西：一个可靠的 durability implementation，一个高性能数据结构和算法库。他原来自己做 in-process event log，边角情况越来越多，最后直接换 SQLite，当成有 ACID 的 ordered KV store。还有人从 JSON、JSONL 一路试到 SQLite，最后停下来。
这才是这帖真正有价值的地方。标题像是在说「数据库选型」，评论最后其实在说「别再手搓半个数据库」。如果你的 workflow state 已经有更新、索引、约束、事务、replay、inspect 这些需求，那一堆文件很快会变成自制数据库。SQLite 的魅力不是它能替代 Postgres，而是它能替代你那个没有名字、没有 WAL、没有 query planner、没有备份语义的临时状态目录。
当然，HN 另一半人马上把车开回生产系统。levkk 说：I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency.
反方说：SQLite 写是串行的，不等于它必然是瓶颈。Simon Willison 也补了一句：SQLite requires writes run sequentially，但如果只是插入或更新小行，你可能永远注意不到这个队列。很多人把 `doesn't scale` 和 `is a bottleneck` 混在一起了。很多应用真撞到 SQLite 上限时，说明产品已经成功到「迁移数据库是最不值得担心的问题」。
faangguyindia 列了一张单子：用 Go + SQLite 替掉 Intercom、Zendesk、邮件营销、Kanban、Todo、billing、issue tracker、forum、uptime monitor、PagerDuty clone，全部跑同一台服务器，Caddy 在前面，成本降到原来十分之一。他也不装成标准答案，只说自己只用到那些 SaaS 1–5% 的功能。下面马上有人提醒 bus factor：你被车撞了怎么办？
PUSH_AX 更简单：we have an MAU in 7 figures, all backed by SQLite durable objects.
utopiah 在评论里写了一段很适合收尾：
> 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
SQLite 在这篇里不是银弹，它只是把那个问题问得更窄：你要 durable 的到底是什么？是一整个分布式数据库系统，还是一段能留下来的 workflow history？
🔗 [HN 原帖](https://news.ycombinator.com/item?id=48326802) · [文章原文](https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/)