用 Postgres 替代专用工作流引擎
推荐指数 62.0 NO. 014 · 2026.05.29
发布2026/05/28Score115Comments42
为什么值得看
DBOS 提出直接用 Postgres 实现持久化工作流，无需 Temporal、Airflow 等外部编排系统。对已有 Postgres 基础设施的团队，可砍掉一套分布式系统的运维负担，降低可靠性架构的复杂度。
媒体预览
编辑判断
Temporal 和 Cadence 这类专用工作流引擎的痛点从来不是功能不够，而是多一套分布式系统的运维成本——你要管集群、调超时、处理脑裂。DBOS 的取巧之处在于把状态机塞进 Postgres 的 MVCC 和 WAL 里，利用数据库已有的 ACID 和复制机制做容错，本质上是用"我已经信任的组件"替代"我要额外信任的组件"。
不过代价也很明显：工作流吞吐受 Postgres 连接数和锁竞争限制，高频短任务场景可能不如内存型引擎。最该试的人群是已有 Postgres 主架构、工作流以分钟/小时级长事务为主的团队，比如计费结算、审批链路、ETL 管道这类场景。
一个值得观察的信号是，这种"数据库即平台"的思路正在多个方向收敛——从 pgvector 到 pg_graphql，Postgres 正在吞噬周边中间件的功能边界。
社区反馈
意见分歧 46 条评论
核心争论：Postgres能否可靠替代专用工作流引擎，还是牺牲正确性与可扩展性
Continuously amazed by what you can do with few tools, as long as Postgres is a part of your toolkit. I recently developed a distributed queue and it works really great - benchmarks great too, with no race conditions or conflicts. I used SKIP LOCKED so that workers can compete safely. You can also h
Advisory locks are preferred for this anyways because holding a lot of SELECT FOR UPDATE doesn’t scale too well. Edit: Actually I checked this again and apparently the advice has now changed to the inverse.
Citing CockroachDB as an example of scaling Postgres made me spit out coffee. Was this LLM-written?