ハクソク

世界を動かす技術を、日本語で。

耐久性のあるワークフローにはPostgresを使おう

2026年5月29日原文(dbos.dev)

概要

  • Durable workflows は、プログラムの進捗をデータベースに定期的に保存し、障害時に直前の状態から復旧可能
  • 多くのシステムでは 外部オーケストレーター が使われるが、これは複雑化の要因
  • Postgres などのデータベース自体をオーケストレーターとして利用することで、シンプルかつ効率的な設計が実現可能
  • 可用性・スケーラビリティ・観測性・セキュリティ の課題はPostgresの既存機能で十分に対応可能
  • Postgresを活用した durable workflows の利点と具体的な設計案を紹介

Durable Workflowsの基本と課題

  • Durable workflows は、プログラムの進行状況を定期的に データベースにチェックポイント として保存する設計
  • プログラムがクラッシュしても、 最後のチェックポイント から再開できるため、信頼性向上
  • 例えるなら、 ビデオゲームのセーブ機能 と同様の仕組み
  • 一般的には、 Temporal や Airflow、 AWS Step Functions のような 外部オーケストレーター が中心となる構成
  • ワークフローの各ステップの進行・チェックポイント管理・障害時のリカバリを オーケストレーター が担当

外部オーケストレーションの複雑さ

  • 外部オーケストレーター は、設計と運用の両面で 複雑化 の原因
  • Durable workflowsの本質は データベースによる状態管理 にあるため、 専用オーケストレーターは不要 という主張
  • Postgres などのデータベースを直接活用することで、 設計の単純化と効率化 が可能

Postgresを用いたDurable Workflowsの設計

  • アプリケーションサーバー が直接 Postgres と通信し、ワークフローを実行
  • クライアントは、 Postgresのworkflowsテーブル にワークフローを登録
  • サーバーはテーブルを ポーリング してワークフローを取得・実行
  • 各ステップの出力を Postgresにチェックポイント として保存
  • サーバー障害時も、 他サーバーがチェックポイントから復旧 できる設計
  • ロック機構 や 一意制約 を活用し、ワークフローの重複実行を防止

Postgres活用によるメリット

  • 中央オーケストレーター不要、アプリケーションサーバー間で Postgresを介した協調 が可能
  • スケーラビリティ ：サーバー追加で水平方向の拡張が容易、Postgres自体の性能が上限
  • 可用性 ：Postgresのレプリケーションや自動フェイルオーバー機能を活用
  • 観測性 ：ワークフローやステップの状態が Postgresテーブル に蓄積されるため、 SQLクエリ で柔軟に可視化・分析
    • 例：直近1か月でエラーとなったワークフローの抽出など
  • 信頼性・セキュリティ ：外部オーケストレーターを排除し、 Postgresのみが単一障害点 となる設計
    • 既存の アクセス制御・監査 機能をそのまま利用可能
    • 新たなクリティカルインフラの導入不要

Postgres Orchestrationの今後

  • Postgres を用いたdurable workflowsは、 シンプルで高信頼 なシステム構築を実現
  • DBOS など、Postgresベースのdurable executionに特化したプロダクトも登場
  • さらなる情報や実例は以下を参照
    • Quickstart: https://docs.dbos.dev/quickstart
    • GitHub: https://github.com/dbos-inc
    • Discordコミュニティ: https://discord.gg/eMUHrvbu67

まとめ

  • Durable workflowsは データベース中心設計 で本質的にシンプル化可能
  • Postgres の既存機能を活用することで、 大規模・高可用性・高観測性・高セキュリティ を実現
  • 新たなオーケストレーターの導入よりも、 既存インフラの活用 が合理的

Hackerたちの意見

DBOSとTemporalを使ってる人の体験談が気になるな。過去にTemporalを使ったことがあるけど、すごく良かった。ただ、リクエストペイロードやイベントサイズに制限があって、それが解決策を作るときにちょっと不便だったかな。良いエンジニアリングプラクティスを強制するけど、CSVファイルが2MBを超えると特別なロジックを書くのが面倒になることもある。S3にアップロードしてリンクを渡して、ワークフローでダウンロードするっていうのはね。DBOSの経験はどう？運用の複雑さや機能の整合性、他に何か気になることはある？

└

大きなペイロードの問題を解決するために外部ストレージのアプローチがリリースされたよ。100%好きってわけじゃないけど（後付け感があるし、内蔵されてるわけじゃない）、今は初期リリースだから、今のところはこれで解決したと考えてもいいかも。

└

AI生成ワークフローや動画ファイルの処理にDBOSを使ってるよ。Celeryからの移行には時間がかかったけど、うちの場合はやる価値があった。

└

大規模なオンプレミスのTemporalを運用してるんだけど、捨てアカウントだから多分バレるだろうな。1年以上プロダクションで運用してきたけど、個人的には設計が悪くて、遅いし、インフラ的に重すぎると思う。もし200以上のイベントやワークフローを扱って、数百を同時に一日中動かす必要があるなら、インフラに何百万もかかるし、結局すごく使いづらいよ。自分でベンチマークを試してみて、数字はひどいから。営業チームもひどくて、必死だし。開発者の視点から見ると、SDKは結構いいけどね。Nexusにハマらないようにして、営業チームから電話が来たら、法務も同席させることを忘れずに。

└

Temporalはちょっと複雑すぎると思ったけど、君が言ったように、良いエンジニアリングプラクティスを強制するのが一番のポイントだね。それから彼らのクラウドサービスを試してみたけど、価格に驚いたよ。何かをプロダクションに持っていく前に、1,000ドルの無料クレジットを使い切っちゃった。ローカルでTemporalを動かすのも面倒だったしね。結局、彼らのアーキテクチャからインスピレーションを得て、自分でPostgresでやるのが一番だと思う。

└

DBOSは使ったことないけど、今の仕事でTemporalを使ってて、前の仕事でも使ってたから、今は約1.5年の経験があるよ。家では、あまり時間に敏感じゃないホームオートメーションのタスクを処理するために使ってる。ワークフローのレイテンシはそんなに悪くないけど、家の動作イベントでトリガーされるものには使わないかな。非アクティブの後に何かをオフにするためのタイムアウトの話なら別だけど。自分のVPCやK8sクラスターの中で薄いREST APIを前に置いて、イベント駆動のトリガーを助けるのが好きなんだ。これでTemporalの認証やワークフローのステータス確認を気にしなくて済むから、できるだけロジックフリーに保てる。ざっくり言うと、DBトリガーがあって、そのトリガーが直接アクションを起こすか、イベントをキューに入れる。ハンドラーは必要なイベント詳細を持って薄いREST APIを呼び出す。REST APIはこれがワークフローを開始するか、既存のものにシグナルを送るか、無視するかを決める（このパターンは状況によって変わるけど、SignalWithStartは自分にとっては一般的だし、イベントがワークフローを開始する価値がない場合は無視することもある）。親子ワークフローの機能は、単一のオブジェクトのライフサイクルに対して異なる自己完結型の動作を調整する必要があるときに非常に価値があるし、外部要因がオブジェクトの軌道を変えたときにキャンセル可能なのもいい。長い話を短くすると、すごくパワフルで扱いやすいと思うし、ライフサイクルロジックをAPIから引き離すのに本当に役立ってる。ロジックを簡単そうな場所に投げるだけじゃなくて、後で隠れた罠になるのを避けるのに役立つよね。

DBOSはRustをサポートしてないから、https://github.com/tensorzero/durable でかなりミニマルなRust版を実装したよ。結構安定してて拡張性もあるけど、SQLの実装には注意が必要だね。ここにいる読者には興味深いと思うよ。

Conductor OSSはこれをうまくやってるよ。https://docs.conductor-oss.org/devguide/ai/index.html https://github.com/agentspan-ai/agentspan これは基本的にConductorのエージェントSDKレイヤーで、あなたのlanggraph、openAI、vercel、ADKエージェントを耐久性のあるものに変えて、コード変更なしでオーケストレーションを追加できるんだ。

└

うちのプロダクションではキューにRedisを使ってるけど、PostgresやMySQLをキューとして使ってるユーザーも見かけたよ。

Armin RonacherのabsurdはPostgres用の耐久性ワークフローの実装だよ。https://lucumr.pocoo.org/2025/11/3/absurd-workflows/ https://github.com/earendil-works/absurd https://earendil-works.github.io/absurd/ 使ったことはないけど、他の選択肢と比較する価値はあると思う。

└

もし大量のスループットが必要ないなら、absurd（と私たちのRust派生のdurable）は、クライアントサイドを非常にシンプルに保つ素晴らしい選択肢だと思うよ。軽量だから、コーディングエージェントが全体を頭に入れておいて、必要に応じて状態を調べるためにクエリを実行することも簡単だしね。

TB単位のデータにスケールするまで、必要なのはPostgresだけだよ。うちはPostgreSQLを耐久性のあるワークフローエンジン、ベクトル検索、時系列データ、BM25検索、OLTP/OLAPエンジン、キューとして使ってる。https://lobu.ai にとっては基本的に唯一の依存関係だね。主な利点は、すべてのデータを一箇所に集中させることで、複数のシステム間でデータをコピーする心配がなくなること。何かがボトルネックになると、最終的には特定の目的のツールに移行してスケールアウトできるよ。正直なところ、LISTEN/NOTIFYはPGの中で一番脆弱な部分だと思うけど、スケールアウトするまでのスタートとしては大丈夫だよ。

Hacker Newsで議論の続きを見る