SQLite 足够构建持久化工作流

DBOS 最近提出，Postgres 足以满足持久化执行的需求：如果你已经信任你的数据库，就不需要单独编排层。我同意这个方向，并认为可以进一步推进。对于一大类持久化系统，SQLite 就足够了。

持久化的部分

持久化执行常被讨论成需要持久化基础设施。很多情况下并非如此。持久的部分是工作流状态。计算可以保持廉价和可抛弃。这天然适合 Obelisk：工作流进度存储在执行日志中，工作流从持久化的历史重放，活动可以重试。最重要的是保持工作流状态存在且易于检查。

为什么 SQLite 合适

SQLite 的吸引力在于它提供了事务性的持久化状态，而无需引入单独的数据库服务。没有网络跳数，没有额外的控制平面，也没有为了保持工作流安全而新增的操作面。对于许多系统，本地数据库文件正是合适级别的工具。

Litestream 让它可移植

一个明显的担忧是，当实验积累起来后如何处理这些 SQLite 文件。这就是 Litestream 的用武之地。它可以异步地将 SQLite 变更流式传输到兼容 S3 的对象存储。这提供了一种简单的方法，让工作状态靠近运行时，同时仍能将数据库复制出来用于备份、迁移和检查。

需要注意的是，Litestream 复制是异步的。如果 SQLite 卷在复制之前消失，恢复时可能会丢失最新的本地写入。这对于许多 AI 和实验性工作流来说是可以接受的，但这不等同于高可用的共享数据库。

即便如此，这仍然产生了一个有用的操作模型：运行一个使用 SQLite 数据库的 Obelisk 服务器，用 Litestream 备份它，并让观察者在需要时拉取感兴趣的数据库。同一个文件可用于本地重放、调试和理解 agent 实际做了什么。

为什么这对 Agent 特别有效

这对于 AI agent 和 AI 生成的工作流尤其有吸引力。这些系统通常是突发性的、实验性的，并且当每个 agent 或租户拥有一个小的自包含状态单元时，更容易推理。在微 VM 或容器中运行一小组微型服务器，每个都有自己的 SQLite 数据库和对象存储备份，通常比一个大型的始终在线的共享系统更合适。它更简单、更便宜，并提供更好的故障隔离。

何时改用 Postgres

SQLite 并非适用于所有部署场景。Obelisk 也支持 Postgres，当你需要更高的可用性、更广泛的共享可伸缩性，或其他更适合网络数据库的部署属性时，Postgres 是正确的选择。当你不想采用异步复制到对象存储的持久化模型时，它也是更好的选择。

许多工作流系统在第一天并不需要这些，也不应该从一开始就使用比其状态实际需要的更多的基础设施。在大量场景中，本地 SQLite 数据库加上 Litestream 备份到 S3 就足够了。在其周围添加廉价的工作节点，你就得到了一个持久化系统，基础设施开销很小。对于 AI agent 的世界，这可能是最合理的默认选择。