Microsoft pg_durable: PostgreSQL 数据库内的持久化执行

Microsoft 已开源 pg_durable，这是一个旨在将持久化执行直接引入数据库的 PostgreSQL 扩展。通过允许开发者使用 SQL 定义长运行、容错的工作流，pg_durable 消除了对外部编排器、独立的队列系统或复杂的状态跟踪表来管理后台任务的需求。

PostgreSQL 内部的持久化执行

pg_durable 支持创建基于 SQL 的函数图，由 PostgreSQL 执行并进行检查点记录。如果数据库崩溃、重启或特定步骤失败，执行将从最后一个持久化检查点恢复，而不是需要重新启动整个流程。这种方法将编排逻辑（重试状态、进度跟踪和检查点记录）从应用层移到了数据库本身。

核心能力

  • SQL 原生定义：工作流使用可组合的操作符，如 ~> 和 |=> 进行定义。
  • 零基础设施：该系统作为 PostgreSQL 扩展运行，无需 Redis、Temporal 或 Airflow 等外部服务。
  • 数据库感知原语：该扩展为调度、条件逻辑和并行执行提供了一流的支持。
  • 容错性：函数状态持久化到 PostgreSQL，确保在崩溃和故障转移后仍能生存。

示例工作流

用户可以启动一个持久化函数来分步处理数据。例如，以下 SQL 启动了一个获取未处理文档并进行批量更新的过程：

SELECT df.start(
    'SELECT id FROM documents WHERE processed = false LIMIT 100' |=> 'batch'
    ~> 'UPDATE documents SET processed = true WHERE id = ANY($batch)'
);

目标工作负载与使用场景

pg_durable 针对那些计算需要靠近数据以降低延迟和架构复杂性的工作负载进行了优化。

推荐使用场景

  • 向量嵌入流水线：对数据进行分块、调用嵌入 API，并将结果 upsert 到 pgvector 中。
  • 摄取流水线：对大批量数据进行暂存、去重、转换和发布。
  • 定期维护：检测数据库膨胀、通知管理员，并在获得批准后执行清理操作。
  • 扇出聚合：并行运行独立的查询并合并结果。
  • 外部 API 工作流：直接从 SQL 处理增强、分类和 Webhook 风格的调用。

何时避免使用 pg_durable

  • 简单查询：如果任务只是单个 INSERT ... SELECT 或标准的 SQL 语句，则无需使用 pg_durable。
  • 低延迟：它不适用于亚毫秒级的同步请求处理。
  • 重外部依赖的工作流：如果工作流跨越许多异构系统且主要存在于 PostgreSQL 之外，那么通用的编排器会更合适。
  • 复杂的应用逻辑：无法映射到 SQL 步骤、分支、循环或 HTTP 调用的逻辑应保留在应用层。

技术架构

基于 pgrx 构建，pg_durable 是一个完全在服务器内部运行的 PostgreSQL 扩展。它由用于构建函数图的 SQL DSL 和管理执行的后台工作进程（background worker）组成。

底层框架

  • duroxide：一个持久化任务框架，提供编排运行时，包括确定性重放、检查点和定时器。
  • duroxide-pg：为 duroxide 提供基于 PostgreSQL 的状态提供者，将运行时状态（实例、历史记录和工作队列）持久化在专用的 duroxide.* 模式下。

数据组织

  • df.* 模式：存储 DSL 图、节点、实例和变量。
  • duroxide.* 模式：存储由 duroxide-pg 提供者拥有的内部运行时状态。

安装与部署

pg_durable 目前处于 Preview 阶段。标记的发布版本为 amd64 架构上的 PostgreSQL 17 和 18 提供 Debian 包。

设置过程

  1. 将软件包安装到 PostgreSQL 安装目录中。
  2. 将 pg_durable 添加到 shared_preload_libraries。
  3. 重启 PostgreSQL。
  4. 创建扩展：CREATE EXTENSION pg_durable;

安全与多租户

访问通过显式授权进行管理。管理员必须使用 SELECT df.grant_usage('app_role'); 来授予应用角色访问权限。行级安全性 (RLS) 确保用户只能管理自己的持久化函数实例和节点。后台工作进程角色（默认：azuresu）必须是超级用户，以绕过 RLS 并管理所有用户实例。

社区观点与权衡

工程师之间的讨论表明，在偏好“数据库即编排器”方法的人与偏好传统外部 DAG 调度器的人之间存在分歧。

关键反方观点

  • 控制流位置：一些开发者认为控制流和队列逻辑应该驻留在版本控制的代码（Git）中，而不是在数据库内部。
  • 资源争用：人们担心在数据库——通常是基础设施中最难扩展的部分——中加载额外的长运行后台任务，会产生影响。
  • 与 Temporal 的比较：一些用户质疑 pg_durable 与 Temporal 等工具的对比，指出“何时避免使用”部分表明其功能范围更限制，因为它是有意为 SQL 形状的。
  • 内平台效应：一位批评者指出，这可能是一个“内平台效应”的案例，即工具在数据库环境中重新创建了编程语言的能力（如状态挂起与恢复）。

Sources