SQLite：持久化工作流的全部所需

# 持久化工作流，SQLite 足矣 来源：https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/ 2026\-05\-29DBOS 最近提出，Postgres 足以支撑持久化执行（https://www.dbos.dev/blog/postgres-is-all-you-need-for-durable-execution）：如果你已经信任你的数据库，就不需要额外的编排层。我赞同这个方向，并且认为这个思路可以进一步推进。 对于很大一类持久化系统来说，SQLite 足矣。 图示：多个 Obelisk 工作节点写入 SQLite 状态，Litestream 将其备份到 S3，观察者按需拉取感兴趣的数据库进行检查 ## 持久化部分 持久化执行常常被讨论得好像需要持久化基础设施。但许多时候并不需要。持久化的部分是工作流状态。计算部分可以保持廉价和可丢弃。 这与 Obelisk 天然契合：工作流进度保存在执行日志中，工作流从持久化的历史记录中重放，活动可以重试。最关键的是保留工作流状态并便于检查。 ## 为什么 SQLite 适合 SQLite 的吸引力在于，它无需引入单独的数据库服务就能提供事务性的持久化状态。没有网络跳转，没有额外的控制平面，也没有为保障工作流进度安全而新增的运维面。对于许多系统来说，本地数据库文件恰恰是合适程度的机制。 ## Litestream 使其可移植 显而易见的担忧是，当实验开始累积时，如何处理这些 SQLite 文件。这正是 Litestream（https://litestream.io/）的用武之地。它可以异步地将 SQLite 变更流式传输到兼容 S3 的对象存储。这提供了一种简单的方式：将工作状态保留在运行时附近，同时将数据库复制出去用于备份、迁移和检查。 需要注意的是，Litestream 的复制是异步的。如果 SQLite 卷在最新本地写入尚未复制之前消失，恢复时可能会丢失这些写入。这对于许多 AI 和实验性工作流来说是可以接受的，但这与高可用的共享数据库不是一回事。 但这仍然引出一个有用的运营模型：运行一个带有 SQLite 数据库的 Obelisk 服务器，通过 Litestream 进行备份，并在需要时让观察者拉取感兴趣的数据库。同一个文件可用于本地重放、调试以及理解代理实际执行的操作。 ## 为什么这对代理特别有效 这对于 AI 代理和 AI 生成的工作流尤其有吸引力。这些系统往往是突发性的、实验性的，并且当每个代理或租户拥有一个小的自包含状态单元时，更容易推理。一个由微型虚拟机或容器组成的轻量服务器集群，每个都有自己的 SQLite 数据库和对象存储备份，通常比一个永远在线的大型共享系统更合适。它更简单、更便宜，并且提供了更好的故障隔离。 ## 何时改用 Postgres SQLite 并非适用于所有部署形态。Obelisk 也支持 Postgres，当你需要更高的可用性、更广泛的共享可扩展性，或其他更适合网络数据库的部署特性时，Postgres 是正确的选择。当异步复制到对象存储不是你想要的持久化模型时，它也是更好的选择。 许多工作流系统在第一天并不需要这些，并且不应该以比其状态实际需求更多的基础设施起步。 在大量情况下，本地 SQLite 数据库加上 Litestream 备份到 S3 就足够了。再在其周围添加廉价的工作节点，你就得到了一个持久化系统，所需基础设施极少。对于 AI 代理的世界来说，这可能是最合理的默认选择。