HN28972

Microsoftがデータベース内での「持続的な実行」を実現する「pg_durable」をオープンソース化！

pg_durable: Microsoft open sources in-database durable execution

coffeemug・約2か月前

議論

11件

0：coffeemugスレ主▲289約2か月前

Microsoftが、PostgreSQL向けにデータベース内での持続的な実行（Durable Execution）を可能にする新ツール「pg_durable」をオープンソースとして公開しました。これにより、複雑なワークフローや長時間実行される処理においても、障害発生時の再開や整合性の確保が劇的に容易になります。分散システムや信頼性の高いバックエンド開発を行っているエンジニアにとって、見逃せないツールが登場しました。

リンク先:https://github.com/microsoft/pg_durable

1：levkk約2か月前

2026年はPostgresキューの年になるね！（DBOS0、pgQue1）コミュニティがこれに貢献して、使える選択肢を増やしてくれているのは素晴らしいことだと思う。

ただ、元アプリエンジニアとしては、キューのロジックはコードとしてGitで管理したい派なんだよね。まあ、適切なツールがあれば考えも変わるかもしれないけどさ。:)

2：faxmeyourcode約2か月前

Apache AirflowのようなDAGスケジューラがずっと前に解決済みの古い問題に対して、これは的外れな解決策に思えるな。

なぜ制御フローをコードじゃなくてデータベースに保存したいのか？ちょっと不思議な感覚だ。

プロジェクトを否定するつもりはないんだけど、今のところ良さがピンとこないな。

3：kilobaud約2か月前

使わないほうがいい場合
…
ワークフローが主にPostgresの外部に存在し、複数の異種システムにまたがる場合

これってTemporalのようなものとどう比較できるの？この推奨事項が示唆する制限について、何か誤解してるかな？

4：jraedisch約2か月前

理解が正しければ、Absurd（Pi LLM harnessの開発者によるもの）は純粋なDBアプローチを可能な限り最小限に抑えるものだよね。自分もこのトピックを学び始めたばかりだけど。

https://github.com/earendil-works/absurd

5：oa335約2か月前

DBの外側で動くオーケストレーションツールじゃなくて、なぜこれを使いたくなるのか誰か教えてくれない？Readmeやサンプルを読み通したけど、まだ何がしたいのかよく分からないんだ。

6：TuringNYC約2か月前

仕事でAzureに縛り付けられてるんだけど、AzureのPostgresがモダンな技術に追いついてくるのをいつも待たされてる感じ。

例えばこれとか使えないしね：https://www.paradedb.com/blog/hybrid-search-in-postgresql-the-missing-manual

それに、超高次元ベクトルデータも使えない。

pg_durableをオープンソースにしてくれるのはありがたいけど、AWSで普通にできるレベルのことをまずは採用してくれないかな？

7：joelthelion約2か月前

データベースって、ただでさえスケールさせるのが最も難しいインフラの一つじゃない？なんでそこにさらに時間のかかるジョブを詰め込もうとするの？

8：CharlieDigital約2か月前

ドキュメントや例を読んでも、いくつか不明確な点があるんだよね。

df.wait_for_schedule()

この呼び出しはどういう仕組み？アプリから呼び出す場合、べき等（idempotent）なのかな？同じパラメータで2回実行したら2回分カウントされる？それともクエリコンソールから手動で1回だけ実行する想定？それともマイグレーションスクリプトの一部として走らせるもの？

これ[0]については：

-- 人間の応答待ち（5分のタイムアウト）
~> (df.wait_for_signal('approval', 300) |=> 'sig')

~> df.if(
    $SELECT NOT ($sig::jsonb->>'timed_out')::boolean
        AND ($sig::jsonb->'data'->>'approved')::boolean$,

timed_outはタイムアウト時に返される固定定数なのかな？

あと、エラーや例外をどう扱うかもすぐには分からないな。

[0] https://github.com/microsoft/pg_durable/blob/main/examples/invoice-approval/sql/05_start_workflow.sql

9：7373737373約2か月前

これって、いわゆる「内部プラットフォーム効果（Inner-platform effect）」の類じゃないかな？もし主要なプログラミング言語やVMが、決定論的で、計測可能かつ制御可能な段階的実行、そして実行状態のサスペンド、シリアライズ/デシリアライズ、再開をサポートしていれば不要なものなんじゃない？

https://en.wikipedia.org/wiki/Inner-platform_effect

10：ijustlovemath約2か月前

私たちはPostgRESTを使ってPostgres上で非常に機能的なジョブキューを作ったよ。自動的にREST APIが生成されるから、新しいクライアントを作るのがすごく楽になるし、本当におすすめ。