你要给十万份文档生成向量：切分文本、调用接口、写回数据库。任务跑到一半，数据库重启了。已经完成的部分要不要重做？失败的那一批从哪里接上？传统做法往往要再拼一套 Cron、队列和 Worker。微软开源的 pg_durable 想把这件事收回 PostgreSQL 里：任务走到哪，就把进度存到哪，重启后接着跑。
这里的 PostgreSQL，简称 Postgres，是常用的开源关系型数据库。需要先说清：这不是 PostgreSQL 核心新增的原生能力，而是微软发布的扩展项目。本文事实均来自该项目的 GitHub 仓库，尚无第三方测试或用户案例交叉验证。
它把任务拆成一串可续跑的步骤
pg_durable 让开发者用 SQL 函数定义工作流。SQL 函数就是保存在数据库里、能由 SQL 调用的一段程序。系统把函数表示成一张 SQL 步骤图，并在步骤之间建立持久检查点——像长途行程每到一站就盖章，途中出故障，不必回到起点。
微软称，数据库崩溃、重启或某一步失败后，任务会从最近的检查点恢复。重试状态、执行进度和检查点也保存在 Postgres 中。工作流通过 df.start(...) 启动，调用方会拿到一个实例 ID；运行中和结束后，都可以查询 df.instances 等数据库表查看状态和结果。
项目还支持 fan-out aggregation：把彼此独立的查询并行分发，完成后再汇总。仓库列出的场景包括向量嵌入、批量数据摄取、定时维护和外部 API 调用。例如，一批文档可以先找出未处理记录，再分步处理并写回状态。
少维护一套系统，才是它的吸引力
后台任务通常由几样东西拼成：Cron 负责定时触发，队列暂存和分发工作，Worker 在后台真正执行，另设状态表记录进度。组件一多，失败恢复、权限、备份和监控也会散在不同地方。
pg_durable 的主张是把工作流和业务数据放在一起。对已经用 Postgres 保存状态的团队，这可能减少一部分轮询 Worker、队列消费者、调度器和自建状态表；数据库管理员也能直接用 SQL 审计任务。不过，仓库所称的“无需额外服务基础设施”仍是厂商表述，不能理解成所有外部组件都会消失。
它也有明确取舍。这个模型刻意做成“SQL 形状”，适合能拆成 SQL 步骤、分支、循环或 HTTP 调用的流程。若任务依赖任意应用代码、非 HTTP SDK，或横跨许多异构系统，项目自己也建议包装成 SQL 函数、放到 HTTP 服务后面，或者继续使用通用编排器。要求亚毫秒级同步响应、无法安装扩展或运行后台 Worker 的环境，同样不适合。
目前，项目的正式发布提供面向 amd64、PostgreSQL 17 和 18 的 Debian 包与 Docker 镜像；仓库明确警告，现成镜像只用于评估和学习，不应投入生产。pg_durable 也已集成进微软新推出的 PostgreSQL 云服务 Azure HorizonDB，可在那里试用。
局限与未知
- 崩溃恢复、失败重试、并行执行和审计能力都只有微软仓库的说明，缺少独立验证与性能数据。
- 材料没有交代 exactly-once（一次且仅一次）语义、外部 API 产生副作用时如何去重，以及检查点的事务边界。任务“恢复”不等于外部操作绝不会重复。
- 生产部署限制、性能开销和完整适用范围仍不清楚；现有 arm64 镜像也尚未发布。