文章摘要
微软开源的pg_durable项目为PostgreSQL提供了持久化执行功能，让用户可以直接在数据库中创建容错的长时SQL工作流。它通过检查点机制确保工作流在崩溃、重启或步骤失败后能从中断处恢复，无需额外基础设施。适合需要在数据旁运行可靠工作流的团队，尤其后端工程师、DBA及数据/AI管道开发者。该工具将计算贴近数据，简化了传统需要拼接定时任务、队列等组件的复杂方案。
文章总结
PostgreSQL 持久化执行扩展 pg_durable
项目概述
pg_durable 是微软开发的 PostgreSQL 扩展，为长期运行的 SQL 函数提供容错执行能力。它允许开发者在数据库中定义工作流，自动处理故障恢复和断点续传，无需额外的基础设施支持。
核心功能
- 持久化执行：工作流状态持久存储在 PostgreSQL 中，可抵御崩溃、重启和故障转移
- SQL 原生：使用可组合的操作符（如
~>和|=>）在 SQL 中定义工作流 - 数据库感知：提供调度、条件和并行执行等原生支持
- 零额外基础设施：作为 PostgreSQL 扩展运行，无需 Redis 或 Temporal 等外部服务
适用场景
目标用户
- 希望工作流与数据共存的 backend 和数据工程师
- 需要可审计、可重启自动化运维的 DBA 和 SRE
- 构建需要行级/文档级/批处理持久化执行的数据或 AI 管道的团队
典型工作负载
- 向量嵌入管道：分块、调用嵌入 API 并更新到 pgvector
- 数据摄取管道：暂存、去重、转换和发布大批量数据
- 并行聚合查询：并行执行独立查询后合并结果
- 外部 API 工作流：从 SQL 发起的数据增强、分类和 webhook 调用
技术实现
pg_durable 作为 PostgreSQL 扩展构建，包含： 1. 用于构建函数图的 SQL DSL 2. 托管 duroxide 运行时的后台工作进程 3. 基于 duroxide-pg 的 PostgreSQL 状态存储
架构层次：
PostgreSQL
└── pg_durable 扩展
├── SQL DSL
└── 后台工作进程
└── duroxide 运行时
└── duroxide-pg 状态提供器
快速示例
sql
-- 分步处理数据的持久化函数
SELECT df.start(
'SELECT id FROM documents WHERE processed = false LIMIT 100' |=> 'batch'
~> 'UPDATE documents SET processed = true WHERE id = ANY($batch)'
);
安装部署
提供 Debian 包（支持 PostgreSQL 17/18）和源码安装方式。安装后需：
1. 将 pg_durable 添加到 shared_preload_libraries
2. 重启 PostgreSQL
3. 创建扩展：CREATE EXTENSION pg_durable
多用户配置
扩展安装后需显式授予应用角色访问权限。行级安全(RLS)确保用户只能管理自己的工作流实例。
授权示例： ```sql -- 授予特定角色使用权 SELECT df.grantusage('approle');
-- 或创建中间角色 CREATE ROLE pgdurableuser NOLOGIN; SELECT df.grantusage('pgdurableuser'); GRANT pgdurableuser TO appbackend, etl_service; ```
项目状态
当前处于预览阶段，采用 PostgreSQL 许可证。安全漏洞请通过 SECURITY.md 中的流程报告。
评论总结
以下是评论内容的总结，平衡呈现不同观点并保留关键引用：
支持Postgres队列的观点
社区贡献的价值
- "2026 is the year of the Postgres queue! It's awesome that the community is contributing this" (levkk)
- "Seems like an interesting idea to add durability and resumability to lengthy cron jobs" (redmonduser)
潜在应用场景
- "I hope it could be used to export pg_dump to s3...trigger maintenance jobs via lambda" (rastignack)
质疑/保留意见的观点
与现有方案的比较
- "Why not use DAG schedulers like Apache Airflow? Why store control flow in DB?" (faxmeyourcode)
- "How is this comparable to Temporal?" (kilobaud)
技术可行性担忧
- "Isn't DB already hard to scale? Why add long-running jobs?" (joelthelion)
- "Why use this over external orchestration tools?" (oa335)
实现方式争议
- "Why not build on pgmq?" (cpursley)
- "Absurd minimizes pure DB approach" (jraedisch)
平台限制的补充观点
- "Azure PG lacks现代功能 like hybrid search" (TuringNYC)
- "Is this an open-sourcing of internal tool?" (mikey_p)
关键分歧点在于：数据库内工作流是否比代码/外部工具（如Airflow）更优，以及Postgres作为任务队列的扩展性。支持者看重集中化管理，反对者则强调专业工具成熟度和性能隔离。