【Microsoftの狂気】PostgreSQLに直接ワークフローエンジンを埋め込む拡張機能『pg_durable』が公開！TemporalやDurable Functionsはオワコン化するのか？

分散システムやAIエージェントのシステムを構築したことがある開発者なら、誰しもが「耐久実行（Durable Execution）」の難しさに頭を悩ませたことがあるはずだ。一時的なネットワークエラー、外部APIのタイムアウト、あるいはコンテナのクラッシュ。これらが発生した際に、実行中のマルチステップ・ワークフローを「クラッシュした時点から完全に再開（レジューム）」させるためには、TemporalやAzure Durable Functions、AWS Step Functions、Airflowといった、極めて重厚で複雑な外部オーケストレーターが必要不可欠とされてきた。アプリ層とデータベース層、そしてメッセージキューを往復するそのインフラは、システムの肥大化と運用の悪夢を招く原因でもあった。

そんな中、Microsoftがプレビュー公開したPostgreSQL用の拡張機能『pg_durable』は、これまでのインフラ設計の常識を根底から覆す、まさに「狂気」とも言えるアプローチを提示している。なんと、外部のオーケストレーターをすべて排除し、PostgreSQLデータベースエンジンそのものの内部に「ステートフルな耐久実行ランタイム」を直接埋め込んでしまったのだ。これにより、データベース自体にステートフルな実行耐久性を持たせる、新しいデータベース・パラダイムが誕生した。

【事象の全貌と背景】：なぜ今、データベースへのランタイム統合なのか？

ここ数年、開発コミュニティでは「Postgres is eating the world（Postgresが世界を飲み込んでいる）」や「Postgres as everything（何でもかんでもPostgresでやる）」という潮流が爆発的に加速している。リレーショナルデータだけでなく、ベクター検索（pgvector）、時系列データ（TimescaleDB）、メッセージキュー（pgmq）までをPostgres単体に集約し、インフラの「認知負荷」と「コンポーネント数」を極限まで削ぎ落とそうという動きだ。

しかし、これまでは「長期実行されるビジネスロジックやAIパイプラインのオーケストレーション」だけは、Postgresの境界線の外側に置くしかなかった。なぜなら、いつ終わるかわからないAPI呼び出しや、人間の承認待ち（Human-in-the-loop）といったステート（状態）を、データベースのトランザクション内で安全に保持し続けることは不可能だったからだ。通常のデータベース接続でこれを行えば、コネクションプールは瞬時に枯渇し、ロックの競合でシステム全体がハングアップしてしまう。

Microsoftはこの課題に対し、Azure HorizonDB向けに「Durable Functions in Azure HorizonDB」として、そのコアとなる実行エンジン『pg_durable』をオープンソースで公開するという驚くべき決断を下した。これにより、ETLジョブ、AI呼び出し、Cronによる定期タスク、承認ワークフローなどの「長期にわたる、壊れやすいマルチステップ・ワークフロー」を、Postgresのトランザクション保証、レプリケーション、バックアップ、PITR（ポイントインタイムリカバリ）の強力な恩恵をそのまま受けながら、データベース内で完結させることが可能になったのである。

【技術的ディープダイブ】：『pg_durable』の内部アーキテクチャとAI Pipelinesの統合

技術的に見ると、`pg_durable`はデータベースの内部スケジューラとステート管理をPostgreSQLのトランザクションログ（WAL）およびストレージエンジンと密結合させることで、極めて高い堅牢性を実現している。通常のアプリケーションコードで耐久実行を実現する場合、状態のセーブポイントをいちいち外部DBにシリアライズして書き戻す必要があるが、`pg_durable`は自身がデータベースであるため、ステップの実行状態や変数の変更がそのままACID特性を保って永続化される。

さらに強力なのは、この`pg_durable`を汎用の耐久実行基盤として使い、その上位に構築された「AI Pipelines in Azure HorizonDB」との統合だ。現在プレビュー版として公開されているこの仕組みでは、`azure_ai`拡張機能の一部である`ai.*` pipeline APIを使用し、SQL内で宣言的に「AIワークフロー」を構築できる。

具体的には、データソース、チャンク化（Chunking）、埋め込み（Embedding）、抽出、LLMによる生成、ランキング、そして人間の承認といった各ステップをSQLで定義すると、システムが自動的にそれを「耐久実行グラフ」へとコンパイルする。これまで一般的なRAGシステムを構築する際は、「アプリケーション層のサービスがソース行を読み込み、外部の埋め込みAPIを叩き、チャンク化してPostgresのベクターストアに書き戻す」という、極めて壊れやすいクローラーを別建てする必要があった。この方法では、埋め込みモデルを変更した際に、どの行が正常に更新されたかを完璧に追跡するのが困難を極める。

しかし、`ai.*` pipeline APIと`pg_durable`の組み合わせでは、ソース、ステップ、シンク、そして実行履歴のすべてがSQLであり、Postgresのネイティブ機能として処理される。万が一、長大なテキストデータの埋め込み処理の途中でサーバーがクラッシュしたとしても、`pg_durable`が自動的にクラッシュしたその場所からミリ秒単位で実行を再開し、二重実行を防止する二等価性（Idempotency）を担保するのだ。

【コミュニティの生々しい熱量と議論】：「インフラの救世主」か「肥大化したモンスター」か

このMicrosoftによる超攻撃的なOSS戦略に対し、Redditのr/postgresやr/programming、そしてHacker Newsでは、開発者たちの間で激しい論争が巻き起こっている。

熱狂的な賛成派（インフラ極限削減派）は、この発表を諸手を挙げて歓迎している。「もうDocker ComposeでTemporalを設定したり、Azureで高価なオーケストレーターサービスを立ち上げたりする必要がない。Postgresをデプロイするだけで、完全な耐障害性を持ったエージェント駆動システムが動く。コンポーネントが1つ減るだけで、開発効率は10倍になる」という声が上がっている。特に、近年注目を集める「Durable Agents（持続可能なAIエージェント）」の実行基盤として、このDB直結の耐久実行エンジンは極めて魅力的だ。

一方で、経験豊富なデータベース管理者（DBA）やエンタープライズのアーキテクトからは、強い懸念や「悲鳴」に近い批判も噴出している。

「PostgreSQLはいつからオペレーティングシステムになったんだ？」
「データベースに外部APIへのHTTP呼び出し（Durable HTTP call）や、長時間の計算を実行させるなんて、データベースリソースの管理として最悪のアンチパターンだ」
「APIのタイムアウト待ちでDBのワーカースレッドが占有されたら、通常のOLTPクエリのパフォーマンスはどうなるのか？ 懸念されるCPUやメモリのノイズマイナー問題に対するリソース隔離がどこまで徹底されているのか、プレビュー段階ではまだ信頼できない」

このように、コンポーネント統合のメリットと、データベースという最も重要な単一障害点（SPOF）への負荷集中というリスクの間で、コミュニティの評価は真っ二つに分かれている。

【今後の展望とエコシステムへの影響】：パラダイムシフトの始まり

『pg_durable』の登場は、単なる一機能の追加に留まらず、バックエンド開発におけるインフラ設計の「パワーバランス」を変える可能性を秘めている。これまでは、アプリケーション層が「知能（ロジックと実行状態）」を持ち、データベース層は「静的なデータストレージ」に過ぎないという境界線が明確に引かれていた。

しかし、データベース自身が「永続的な計算ランタイム」を内包したことにより、アプリケーションはよりステートレスで軽量な薄いラッパーとなり、システムの本質的な信頼性とビジネスロジックの耐久性はすべてデータベース内で担保されるという、「データベースオンリー（Database-Only）」の時代への扉が開かれた。中規模〜大規模開発において、高価で複雑だった外部オーケストレーション製品の一部は、今後急速にその存在意義を問われることになるだろう。

Microsoftがこの狂気的な機能をまずマネージドのAzure HorizonDBでプレビューとして展開し、かつそのエンジンとなる『pg_durable』をオープンソース（GitHub: https://github.com/microsoft/pg_durable ）として公開したことで、AWSやGCP、あるいはSupabaseといった他のPostgresベンダーがどのように追随するのか。データベースが「単なるデータの箱」から「死なないプロセスの実行エンジン」へと進化する、不可逆なパラダイムシフトが今、静かに始まっている。