SQLite is all you need for durable workflows：为可持久化工作流减负

背景

在分布式系统和可持久化执行（Durable Execution）领域，DBOS 近期提出了一种观点：如果你已经信任你的数据库，那么 Postgres 就是实现可持久化执行所需的全部基础设施，无需引入额外的编排层。这一观点引发了广泛讨论，其核心逻辑在于简化架构，减少不必要的组件依赖。

然而，随着 AI 智能体（AI Agents）和实验性工作流的兴起，系统对“可持久化”的需求呈现出新的特征：高并发、突发流量、状态隔离以及低成本试错。在这种背景下，将“Postgres 即全部”的理念进一步推演，便诞生了“SQLite 即全部”的主张。这篇文章旨在论证，对于大量 AI 和实验性工作流而言，本地 SQLite 数据库配合异步备份，不仅足以满足可持久化需求，而且在架构简洁性、成本控制和故障隔离方面优于传统的共享数据库方案。

核心内容

可持久化的本质：状态而非计算

可持久化执行通常被误解为需要昂贵的、高可用的持久化基础设施。事实上，在大多数场景下，真正需要“持久化”的仅仅是工作流状态（Workflow State），而计算资源（Compute）可以保持廉价且可丢弃（Disposable）。

以 Obelisk 为例，其工作流进展存储在执行日志中，工作流可以从持久化的历史中重放，活动（Activities）也可以进行重试。最关键的是，必须保留工作流状态并使其易于检查。这种模式天然适合轻量级的存储方案。

为什么 SQLite 是理想选择

SQLite 的吸引力在于它提供了一种事务性的持久化状态，而无需引入独立的数据库服务。这意味着：

1. 无网络跳数（No Network Hop）：数据读写直接在本地进行，延迟极低。
2. 无额外控制平面：无需管理复杂的数据库集群或连接池。
3. 无新增运维表面（Operational Surface Area）：无需维护数据库服务器的可用性、补丁或扩容。

对于许多系统而言，一个本地数据库文件正是维持工作流进展安全所需的恰当层级的机械装置。

Litestream：解决便携性与备份问题

针对 SQLite 文件在实验积累后的管理问题，Litestream 提供了关键的解决方案。它可以异步地将 SQLite 变更流式传输到 S3 兼容的对象存储中。这使得用户可以在保持工作流状态靠近运行时的同时，轻松实现数据库的备份、迁移和检查。

需要注意的局限性：Litestream 的复制是异步的。如果 SQLite 存储卷在本地写入被复制之前消失，恢复过程可能会丢失最新的本地写入。对于许多 AI 和实验性工作流来说，这种“最终一致性”的备份策略是可以接受的；但这与高可用的共享数据库在持久性保证上有所不同。

推荐的操作模型

基于上述分析，文章提出了一种实用的操作模型：

1. 运行一个带有 SQLite 数据库的 Obelisk 服务器。
2. 使用 Litestream 进行备份。
3. 让观察者（Observer）在需要时拉取感兴趣的数据库文件。

同一个 SQLite 文件可以用于本地重放、调试以及理解智能体（Agent）实际执行的操作。这种“单一事实来源”极大地简化了调试和审计流程。

为什么这特别适合 AI 智能体

这种架构对 AI 智能体和 AI 生成的工作流极具吸引力，原因如下：

• 突发性和实验性：AI 工作流往往具有突发流量特征，且处于频繁迭代中。
• 状态隔离：每个智能体或租户拥有小型、自包含的状态单元，更易于推理和管理。
• 架构优势：相比一个大型、始终在线的共享系统，由微虚拟机（Micro VMs）或容器组成的小型服务器集群（每个拥有自己的 SQLite 数据库和对象存储备份）通常更合适。它更简单、更便宜，并提供了更好的故障隔离。

何时使用 Postgres？

SQLite 并非适用于所有部署形态。Obelisk 也支持 Postgres，在以下场景中 Postgres 是更好的选择：

• 需要更高的可用性（High Availability）。
• 需要更广泛的共享扩展性。
• 需要其他由网络数据库更好地支持的部署属性。
• 异步复制到对象存储的持久性模型不符合需求。

许多工作流系统在初期并不需要这些高级特性，因此不应在第一天就引入超出其状态实际需求的过多基础设施。

关键要点

• 核心主张：对于大量可持久化系统，尤其是 AI 工作流，SQLite 配合 Litestream 备份足以替代复杂的分布式数据库编排层。
• 解耦计算与状态：可持久化的核心是状态持久化，计算资源应保持廉价、无状态且可丢弃。
• SQLite 的优势：提供事务性持久化，无网络延迟，无额外运维负担，适合本地执行和调试。
• Litestream 的作用：通过异步流式传输将 SQLite 数据备份到 S3 兼容存储，解决便携性和灾难恢复问题，但需注意异步复制可能带来的数据丢失风险。
• AI 工作流的适配性：AI 智能体通常具有突发性、实验性和状态隔离需求，轻量级的“本地 SQLite + 对象存储备份”架构比大型共享数据库更简单、廉价且隔离性更好。
• Postgres 的适用场景：当需要高可用性、共享扩展性或严格的同步持久性保证时，仍应选择 Postgres 等网络数据库。
• 架构建议：避免过度工程化，许多系统在初期无需引入超出实际需求的复杂基础设施。

意义与影响

这篇文章反映了当前 AI 基础设施领域的一个重要趋势：去中心化与轻量化。随着 AI 智能体从概念验证走向大规模部署，传统的“单体数据库+复杂编排引擎”架构显得过于笨重且昂贵。

1. 降低 AI 开发门槛：通过简化持久化层，开发者可以更专注于智能体逻辑本身，而非维护复杂的数据库集群。
2. 优化成本结构：SQLite 的零运维成本和 Litestream 的低成本对象存储备份，显著降低了实验性 AI 工作流的运行成本。
3. 提升调试效率：本地 SQLite 文件使得工作流的历史记录易于访问和检查，这对于调试非确定性的 AI 行为至关重要。
4. 推动架构范式转移：从“共享状态”向“隔离状态”转变。每个智能体拥有独立的状态单元，不仅提高了系统的可扩展性，也增强了安全性和故障隔离能力。

总之，对于大多数 AI 驱动的工作流而言，“SQLite is all you need”不仅是一种技术选择，更是一种务实的架构哲学：用最简单的工具解决核心问题，仅在必要时引入复杂性。