Microsoft が pg_durable を OSS 化 — Postgres 内で完結する Durable Execution の衝撃

はじめに

2026 年 6 月、Microsoft が PostgreSQL 拡張 pg_durable を OSS として公開した。Hacker News では公開直後に 166 ポイントを獲得し、「Postgres だけで Durable Execution が完結する」という設計思想がエンジニア界隈で話題になっている。

Durable Execution（耐久性のあるワークフロー実行）は、ここ 2 年で Temporal・Restate・DBOS・Inngest などが乱立する一大カテゴリに成長した分野だ。そこに Microsoft が「外部オーケストレーターは要らない、Postgres にやらせろ」というアプローチを正式に投入してきた格好になる。本稿では pg_durable のアーキテクチャ、SQL DSL の書き方、Temporal/DBOS との違い、そして実務でどう使うべきかを整理する。

ニュースの詳細 — pg_durable とは何か

pg_durable は PostgreSQL の拡張機能（extension）として動作する、in-database durable execution フレームワークだ。Microsoft が長年メンテナンスしてきた Durable Task Framework（C# 製、Azure Functions 等で利用）の思想を、Postgres の世界に持ち込んだものと位置づけられている。

仕組みは単純で、ワークフローを「SQL ステップの有向グラフ」として定義し、pg_durable のバックグラウンドワーカーがそれを 1 ステップずつ実行・チェックポイントしていく。途中で DB がクラッシュしても、再起動後に最後に保存されたチェックポイントから自動再開される。アプリケーション層で「どこまで進んだか」を自前管理する必要がなくなる、というのが最大のメリットだ。

技術的な前提は以下のとおり。

対応 PostgreSQL: 17 / 18
実装言語: Rust（pgrx ベース）
配布形態: Debian パッケージが GitHub Releases で提供
動作要件: shared_preload_libraries に pg_durable を追加 → 再起動 → CREATE EXTENSION pg_durable

サポートされるステップタイプは、SQL（SELECT / UPDATE の直接実行）と HTTP（df.http() で外部 API 呼び出し）。進捗状況は df.instances テーブルに記録され、SQL で照会できる。

技術的な背景 — SQL DSL とアーキテクチャ

pg_durable の最大の特徴は、ワークフロー定義そのものを SQL で書くことだ。|=> で結果を名前付き変数に束縛し、~> で次ステップに連鎖させる、独特の DSL を持つ。

たとえば「未処理の請求書を取得 → ステータスを processing に更新 → 外部 API で承認リクエスト」というワークフローは、以下のように書ける。

SELECT df.start(
    (
        ($$SELECT id FROM demo.invoices WHERE status = 'pending'$$ |=> 'inv')
        ~> df.if_rows('inv',
            $$UPDATE demo.invoices
              SET status = 'processing'
              WHERE id = ANY($inv)$$
            ~> (df.http('POST', 'https://approval.example.com/api') |=> 'resp')
        )
    ),
    'invoice-approval-pipeline'
);

各演算子の役割は次のとおり。

|=> — ステップの結果を名前付き変数に格納
~> — 次ステップへの連鎖（順次実行）
df.if_rows() / df.if() / df.join() / df.loop() — 条件分岐・並列実行・ループ
df.http() — 外部 HTTP コール（リトライ・タイムアウト付き）

ステップが完了するたびに、その結果と次に実行すべきポインタが Postgres のテーブルに INSERT される。これにより WAL とトランザクション機構をそのまま使ってワークフロー状態を永続化できる。Postgres の PITR（Point-In-Time Recovery）を取れば、ワークフロー状態と実行コードが同一スナップショットに含まれるという副次的な利点もある。

想定ユースケースとして公式に挙げられているのは、ベクトル埋め込みパイプライン（チャンク化 → API 呼び出し → pgvector への upsert）、ETL の取り込みパイプライン（ステージング → 重複排除 → 変換）、スケジュール型のメンテナンスジョブなどだ。いずれも「Postgres を中心に据えたデータパイプライン」の領域である。

エンジニアへの影響 — Temporal / DBOS と何が違うのか

Durable Execution 戦国時代の 2026 年において、pg_durable の立ち位置は明確だ。比較表で整理する。

観点	pg_durable	DBOS	Temporal
ランタイム	Postgres 拡張（DB プロセス内）	アプリ内ライブラリ（Postgres を状態ストアに使う）	独立クラスタ（Frontend/History/Matching）
ワークフロー定義言語	SQL DSL	TypeScript/Python/Go	TypeScript/Java/Go/Python など
外部インフラ	不要（Postgres のみ）	不要（Postgres のみ）	専用クラスタ or Temporal Cloud
強み	SQL 中心 ETL／PITR で状態ごと復元	同一トランザクション境界で exactly-once	マルチテナント・大規模ファンアウト
弱み	任意のアプリロジックは書けない	1 Postgres を超えると拡張困難	運用負荷・専任チームが要る

ざっくり言うと、pg_durable は「DB 中心のジョブ」を Postgres に閉じ込めて運用したい層に最適化されている。アプリケーションコードを書かず、SQL とちょっとした HTTP コールでパイプラインを表現できるケースなら、外部オーケストレーターを立てる理由は薄い。

逆に Hacker News のスレッドでは批判的な意見も少なくない。「ワークフローの制御フローはコード（Git で管理されるアプリケーションコード）に書くべきで、DB に押し込めると差分管理やレビューが破綻する」という指摘や、「Airflow / Prefect で既に解決済みの問題に見える」という冷ややかな反応がある。これは正しい指摘で、pg_durable のドキュメントにも「ワークフローが Postgres 外に大きく広がり、多様なシステムにまたがる場合は不適切」と明記されている。

実務での適用判断としては、以下のチェックリストが妥当だろう。

副作用が同じ Postgres に閉じているか？ → Yes なら pg_durable / DBOS の候補
ワークフロー定義をアプリのコードと一緒に Git で管理したいか？ → Yes なら DBOS や Temporal
マルチテナント・複数リージョン・秒間数万トランザクションが必要か？ → Yes なら Temporal 一択
既存の Postgres 運用ノウハウを最大活用したいか？ → Yes なら pg_durable が刺さる

Microsoft が公式メンテナとして担いでいる点も実務的には大きい。Azure Database for PostgreSQL に統合される可能性が高く、Microsoft Build 2026 のセッションでも PostgreSQL 機能強化の一環として言及されている。マネージド Postgres を使っている組織にとっては、「外部ワークフローエンジン契約を切れる」という TCO 削減の現実的な選択肢になりうる。

今日のその他のニュース

Redis 8.8 — 配列型・組み込みレートリミッターが GA

Redis 8.8 がリリースされ、新しい配列データ構造と、組み込みのレートリミッターコマンドが追加された。これまでアプリ側で「カウンタ + TTL + Lua スクリプト」で組んでいたレートリミッターを、Redis ネイティブの 1 コマンドで置き換えられる可能性がある。性能改善も含まれているため、定期更新の対象に入れておきたい。

独立系ブラウザ Ladybird、開発体制を刷新

Chromium/WebKit に依存しない第三のブラウザエンジン Ladybird が、プロセスとコントリビューションフローの刷新を発表。Hacker News 本日トップの 733 ポイントを獲得しており、「Web の独占構造を崩しうる存在」として再注目されている。本格的な実用にはまだ距離があるが、エンジン多様性の観点では大きな前進だ。

Ruby Bundler に「cooldown」機能 — サプライチェーン攻撃対策

新規 gem を即座に依存に取り込まないよう、一定期間「枯らす」ための cooldown 機能が Bundler に追加。npm 周辺でも類似の議論が活発化しており、エコシステム全体で「新しすぎるパッケージは入れない」というデフォルト設定が広がる流れだ。Gemfile のレビュー観点に追加しておきたい。

まとめ

pg_durable は「Postgres だけで Durable Execution を完結させる」という、ここ数年の DBOS 系トレンドを Microsoft が公式に追認した形のプロダクトだ。SQL DSL でワークフローを定義し、Postgres の WAL とトランザクションで状態を永続化するというアプローチは、SQL 中心の ETL/ベクトル/メンテナンスパイプラインに非常に良くフィットする。

一方で、アプリケーションロジックの制御フローを丸ごと DB に押し込むのは反パターンであり、ユースケースの見極めが本質的に重要だ。Temporal や DBOS との比較を踏まえ、自分たちのワークフローが「Postgres に閉じているか / 飛び出すか」で選定するのが現実的な落としどころになる。今後 Azure Database for PostgreSQL のマネージド機能として展開される可能性も高く、Postgres エコシステム全体での Durable Execution 標準化に向けた一手として注目しておきたい。