DBOS在5月28日发布了一篇技术文章，标题很直接：Just Use Postgres for Durable Workflows。

它的主张也很直接：持久化工作流的核心，不一定是外部编排器。很多时候，核心只是把程序执行进度定期写进数据库。进程挂了，worker换了，任务还能从检查点继续跑。

反常点在这里。

过去谈到可靠执行多步骤任务，很多团队会想到Temporal、Airflow、AWS Step Functions这类系统。DBOS则把问题往回推了一步：如果应用本来就有Postgres，为什么不能让Postgres同时负责记录状态、协调worker和恢复执行？

我更在意的是，这个判断会不会改变一部分团队的选型顺序。不是“专用编排器没用了”，而是“在已有Postgres基础设施里，外部编排器是不是必须第一天就上”。

持久化工作流，先看谁在记账

持久化工作流可以理解成给程序执行过程“存档”。

一个订单履约、支付补偿、AI任务流水线，通常不是一步完成。它可能要调用多个服务，写多张表，等待外部结果，还要处理失败重试。

如果中途进程崩了，系统不能只说“重跑一遍”。更稳的做法是：每完成一步，就把结果和进度写入持久化存储。下一个worker接手时，从最后一个已完成步骤继续。

这就是检查点。

外部编排模式里，中心编排器负责创建workflow记录、派发步骤、接收worker结果、写入检查点，并在失败后重新派发任务。Temporal、Airflow、AWS Step Functions都可以放进这一类里看，虽然它们的目标场景和抽象层次并不相同。

DBOS提出的Postgres-backed模式更贴近应用数据库。

客户端在Postgres的workflows表里创建记录。应用服务器轮询这张表，加锁领取任务，执行步骤，再把每一步结果写回Postgres。多个worker之间依靠数据库锁、完整性约束和检查点表协同，避免同一个workflow被重复执行或重复提交。

对比项外部编排模式Postgres-backed模式
谁调度中心编排器派发任务应用服务器轮询Postgres领取任务
谁写检查点worker回传给编排器，再由编排器写入存储worker直接写回Postgres
失败后怎么恢复编排器把任务重派给其他worker其他worker从Postgres检查点恢复
多worker怎么协同编排器维护状态和调度数据库锁、完整性约束、检查点表协同
新增关键系统编排器及其配套存储、权限和监控主要关键故障点变为Postgres本身

这张表背后的工程问题很朴素：谁来记账，谁来派活，谁来保证别派重。

DBOS的答案是，既然Postgres已经擅长事务、锁、约束和持久化，就让它多做一步。少一层系统，就少一组API、权限、升级、监控和事故演练。

对小型平台团队或单应用团队，这个吸引力很实在。架构图少一块，值班手册也可能少一章。

简化成立的前提，是数据库扛得住

DBOS的优势论点，是把扩展性、可用性、可观测性和安全边界，转化成已有Postgres运维问题。

扩展性上，原文称单Postgres服务器在其基准测试中可达到每秒数万级workflow处理能力。这个数字来自DBOS自己的基准链接，不能直接外推成所有业务场景的保证。

可用性上，Postgres已有流复制、自动故障转移，以及云厂商托管的多可用区部署。安全上，团队也可以继续沿用数据库权限、审计和网络边界，而不是给新编排系统再开一套门。

可观测性是一个容易被低估的点。

如果workflow和step都在关系表里，工程师可以直接用SQL查失败任务、耗时异常步骤、某个用户关联的执行记录。这比面对专用系统的内部存储或查询接口，更接近日常排障方式。

但账不能只算一边。

Postgres会变重。它不只承载业务数据，还要承载任务队列、检查点写入、worker抢锁和排障查询。数据库从“业务状态存储”变成“业务状态加执行状态中枢”。

这对后端工程师意味着，代码会更贴近数据库事务和锁语义。好处是少学一套编排平台，坏处是要更认真地处理幂等、锁竞争、重试和表膨胀。

对平台负责人来说，动作更具体：可以先延后采购或部署独立编排器，把Postgres-backed方案放进PoC。评估时不要只跑happy path，要压测锁竞争、检查点写入、worker重启、数据库故障切换和历史数据归档。

如果团队的Postgres已经写入压力很高，或者业务强依赖跨区域高可用，这条路就没有看起来那么轻。它省掉的是一套编排系统，不是省掉可靠性工程。

这影响选型顺序，不会替代所有专用编排器

最该读这篇文章的，不是所有开发者，而是两类人。

一类是后端工程师。手上有支付补偿、订单履约、通知发送、AI任务流水线这类多步骤任务，但规模还没有复杂到必须上独立平台。对这类场景，Postgres-backed方案至少值得进入设计评审。

另一类是平台或技术负责人。团队正在比较Temporal、Airflow、Step Functions，或者准备把“工作流平台”列成基础设施项目。DBOS这篇文章提供了一个反向问题：现有Postgres能不能先覆盖80%的需求，剩下20%是否真的值得引入新系统。

这不是说Airflow、Temporal、Step Functions落后。

Airflow长期用于数据管道调度。Temporal提供完整工作流语义、SDK生态和运行时能力。Step Functions和AWS权限、事件、托管运维绑定很深。它们的价值在复杂流程、跨服务协调、生态集成和平台化治理里仍然成立。

DBOS挑战的是另一类场景：应用团队只是需要可靠执行多步骤任务，流程主要服务单个应用，状态也天然贴着业务数据库。此时外部编排器可能功能很完整，但也可能太重。

接下来真正要看的，是几个硬变量：

  • 高并发下，Postgres锁竞争会不会拖慢业务写入；
  • 检查点表和历史step记录如何归档，避免无限膨胀；
  • 长事务、轮询和业务查询会不会互相影响；
  • 跨服务workflow的权限边界怎么切；
  • 数据库故障切换时，worker能否稳定恢复且不重复提交。

这些问题回答得好，Postgres-backed工作流就是一个很务实的简化。回答不好，它只是把编排器的问题换了个地方堆起来。

DBOS给出的不是通用处方，而是一种选型提醒：如果你的系统已经围着Postgres转，先别急着把每个可靠执行问题都外包给新平台。能不能少一层，要看数据库是不是已经有能力多扛一层。