Microsoftは、PostgreSQL内部で長期実行・クラッシュ耐性のあるワークフローを直接定義・実行できる拡張機能「pg_durable」をオープンソースとして公開した。外部のジョブキューやワーカーサービスを別途用意することなく、SQLだけでバックグラウンドワークフローの信頼性を確保できる点が最大の特徴だ。

pg_durable とは何か

「Durable Execution（耐久実行）」とは、処理の途中でシステムがクラッシュや再起動しても、最後の成功ステップから自動的に再開できる実行モデルを指す。TemporalやAWS Step Functionsといった外部オーケストレーターがこの概念を広めてきたが、pg_durableはこれをPostgreSQL拡張機能として実装し、データベースの内側に丸ごと収めたのが革新的な点だ。

ワークフローはSQLで定義し、df.start() で起動する。実行エンジンはステップ間で自動的にチェックポイントを作成し、失敗・中断時には最後の成功ステップから処理を再開する。状態管理・リトライカウント・進捗追跡はすべて df.instances テーブルなどPostgresのテーブルに格納されるため、既存の認証モデルやバックアップの仕組みがそのまま使える。

今まで何をしていたか

多くのチームが現在取っている構成は次のようなものだ：

  • pg_cron ＋ ジョブテーブル ＋ ステータスカラム ＋ ポーリングワーカー
  • Airflow / Temporal / Step Functions などの外部オーケストレーターがPostgresをコールバック
  • キュー ＋ ワーカー ＋ 状態テーブルでリトライと部分完了を管理

これらは、「クラッシュ後に途中まで完了した処理をどう扱うか」という問題に対して、アプリケーション側で複雑な状態機械を構築することで対処している。コードは複数のシステムに分散し、部分障害のバグが発生しやすい構造になっている。

主なユースケース

pg_durableが特に力を発揮するシナリオは次のとおりだ：

  • ベクター埋め込みパイプライン: テキストチャンク → 埋め込みAPI呼び出し → pgvectorへのupsert、という一連の処理を1ワークフローに
  • データインジェストパイプライン: ステージング → 重複排除 → 変換 → 公開 の大規模バッチ処理
  • スケジュールドメンテナンス: 肥大化検知 → 承認待ち → 実行、のような人間の承認ステップを含むフロー
  • ファンアウト集計: 複数クエリを並列実行して結果をJOINするパターン
  • 外部API連携ワークフロー: エンリッチメント・分類・Webhookスタイルの呼び出しをSQLから

Azure HorizonDB との連携

pg_durableはMicrosoftの新しいPostgreSQLクラウドサービス「Azure HorizonDB」に組み込み済みで、今すぐ試すことができる。「コンピュートをデータに近づける」というMicrosoftのアーキテクチャ方針の具体的な実装の一つとして位置づけられている。

実務への影響

日本のバックエンドエンジニア・インフラ担当者にとって、次のような場面での活用が考えられる：

  • Airflowを使うほどではないが pg_cron では信頼性が足りない、という「中間の複雑さ」のジョブに最適なレイヤーになる
  • AI/LLM活用で急増しているベクター処理パイプラインを、既存のPostgres環境に閉じた形で構築できる
  • 外部オーケストレーターのライセンスコストやインフラ管理コストを削減できるケースがある

一方で、「任意のアプリケーションロジックをSQLステップにマップできない」「HTTP以外のSDKが必要な場合はラッパーが必要」など、現時点での制約も正直に把握しておく必要がある。すべての非同期ジョブをpg_durableに置き換えるべき、という話ではない。

筆者の見解

このアプローチで評価したいのは、部分最適を積み重ねるのではなく、データのそばで全体を管理するという設計思想だ。Airflow、Temporal、専用キューサービスといった外部コンポーネントを並べて連携させる構成は、それぞれが優れたツールであっても、全体として運用コストが積み重なる。Postgresに状態を持っているチームなら、pg_durableによってその複雑さを一段下げられる可能性がある。

Microsoftがこれをオープンソースとして公開し、Azure HorizonDBにも組み込んだことは、PostgreSQLエコシステムへの本気度を示す動きとして受け止めてよい。Azureのデータベースサービスは地味に着実な進化を続けており、このような「地に足のついた」技術投資はもっと注目されていい。

導入を検討する際は、まず自チームの非同期ジョブの現状を棚卸しするところから始めるのが現実的だ。「pg_cronで管理しきれなくなってきた」「Airflowほどは要らない」と感じているチームにとっては、試す価値のある選択肢になるだろう。

出典: この記事は pg_durable: Microsoft open sources in-database durable execution の内容をもとに、筆者の見解を加えて独自に執筆したものです。