2026年5月29日，一篇题为《SQLite is All You Need for Durable Workflows》的技术博文登上了Hacker News首页，24小时内收获310个赞和182条评论。作者基于Obelisk工作流引擎的实践经验，提出了一个简洁的技术主张：对大量持久化执行系统来说，SQLite就够了，不需要单独的数据库服务。
从Postgres到SQLite的进化
这篇文章是DBOS团队”Postgres is all you need for durable execution”观点的延续和推进。DBOS认为：如果你已经信任你的数据库，就不需要单独的工作流编排层。作者认同这个方向，但进一步推进：”对于一大类持久化系统，SQLite就是你需要的全部。”
核心理由非常直接：工作流状态本身需要持久化，但计算可以是廉价且一次性的。Obelisk的设计哲学正是如此——工作流进度保存在执行日志中，工作流可以从历史记录中重放，活动可以重试。真正重要的是保持工作流状态可访问且易于检查。
SQLite的三重优势
SQLite的吸引力在于三个关键特性：第一，事务性持久化状态——无需引入单独的数据库服务；第二，零网络跳转——没有额外的控制平面，没有新的运维面；第三，文件级简单性——一个本地数据库文件刚好是”正确级别的机械装置”。配合Litestream，SQLite变更可以异步流式传输到S3兼容的对象存储，实现备份、迁移和检查。
社区的激烈争论
HN评论区的反应呈现出典型的”两军对垒”。批评者levkk直言不讳：”我不理解对SQLite的这种痴迷。SQLite是嵌入式数据库，完全不适合管理并发。这正是Postgres、MySQL等数据库服务器存在的理由——允许多进程、多机器同时修改数据。’SQLite万能’群体似乎有点缺乏经验。”
Thaxll则吐槽SQLite的类型系统：”从Postgres切换到SQLite后，我被它糟糕的类型系统震惊了。日期/时间处理感觉像在用30年前的数据库，插入时没有任何约束。”
辩护方的实证数据
但支持方拿出了有力的实证。shukantpal分享了自己的基准测试结果：”SQLite在单节点应用中表现惊人，甚至超过Postgres。Postgres消耗更多内存，且需要通过IPC进行IO跳转。我在自己的Agent框架中测试了不同存储引擎，SQLite在单vCPU上可以达到7500个并发会话，而Postgres会崩溃或耗尽连接。”这个数字令人印象深刻。
PUSH_AX提供了生产环境的背书：”我们从各种Postgres集群转向SQLite，支撑着七位数MAU，全部由SQLite持久化对象支撑。虽然需要改变访问模式，但收益值得。”
中间路线：Temporal的实践
bitexploder的评论提供了一个务实的中间方案：”我使用Temporal来设置工作流。它部署为轻量级本地应用，在独立安装时内部使用SQLite。它在哲学上与本文完全一致，但增加了一个极其丰富灵活的Agent工作界面。”Temporal的Web UI还能方便地检查工作流、审查Agent行为——这正是工作流可观测性的最佳实践。
不只SQLite：DuckDB的挑战
m2f2引入了另一个竞争者：”大量ETL可以在本地完成，不需要企业级数据库。在这种情况下，DuckDB比SQLite好5-10倍，比启动专用Postgres简单/快速几个数量级。”这场SQLite vs DuckDB vs Postgres的竞争，本质上是对”正确级别抽象”的追求——不同的工作负载需要不同的工具。
结论：简单即力量
这篇文章引发的讨论揭示了一个更深层的趋势：开发者正在厌倦过度复杂的架构。在微服务、Kubernetes、专用数据库服务的时代，”一个文件就够了”的SQLite哲学代表了一种回归简单的技术冲动。正如stephenlf半开玩笑的评论：”等不及看下一版——’日志文件就是你需要的全部持久化工作流’。”简单性的终点，也许真的只是写入一个文件。
原文链接：SQLite is all you need for durable workflows
HN讨论：182条评论