SQLite 是所有你需要的 durable workflows
TL;DR · AI 摘要
用 SQLite 和 Litestream 可以实现 durable workflows，适合 AI 代理和实验性系统，无需额外的基础设施。
核心要点
- SQLite 作为工作流状态的存储足够，无需 separate database service。
- Litestream 可以将 SQLite 变更异步流式传输到 S3，实现备份和迁移。
- 对于许多 AI 代理和实验性工作流，SQLite 和 Litestream 是默认的 infrastructure 选择。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- SQLite 作为 durable workflows 的基础设施
- 工作流状态持久性
- 计算资源可 disposable
- SQLite 优势
- 事务性持久状态
- 无需 separate database service
- Litestream
- 异步流式传输到 S3
- 备份和迁移
- AI 代理和实验性工作流
- 默认 infrastructure 选择
- Postgres 适用场景
- 高可用性
- 更广泛共享可扩展性
金句 / Highlights
值得收藏与分享的关键句。
SQLite 是许多 durable systems 的默认选择，无需额外的基础设施。
- Blog
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 replay, debugging, and understanding what an agent actually did.
Why This Works Well For Agents
This is especially attractive for AI agents and AI-generated workflows. Those systems are often bursty, experimental, and 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 a better fit than one large always-on shared system. It is simpler, cheaper, and gives better fault isolation.
When To Use Postgres Instead
SQLite is not the answer to every deployment shape. Obelisk also supports Postgres, and that is the right choice when you need higher availability, broader shared scalability, or other deployment properties that are better served by a network database. It is also the better fit when asynchronous replication to object storage is not the durability model you want.
Many workflow systems do not need that on day one and should not start with more infrastructure than their state actually demands.
In a large set of cases, a local SQLite database plus Litestream backup to S3 is enough. Add cheap workers around it and you get a durable system with very little infrastructure. For the world of AI agents, that may be the most sensible default.