'Postgres があれば十分' — DBOS が示した永続実行エンジンの脱(脱)専用化
‘Postgres があれば十分’ — DBOS が示した永続実行エンジンの脱(脱)専用化
2026 年 5 月 29 日、DBOS のブログ記事が HN の上位に上がり 289 点・123 コメントを集めた。タイトルは挑発的だ — “Postgres is all you need for durable execution” (永続実行には Postgres があれば十分だ)。主張はシンプルだ。ワークフローエンジンの本質的価値であるチェックポイント、単一実行保証、障害復旧を、別のオーケストレータなしに Postgres の標準機能だけで実装できる、というものだ。Temporal の時代が終わるのか、それとも単に「データベース上の万能論」のもう一つの変奏か。
導入 — ‘永続実行’ というカテゴリの台頭
まずカテゴリの定義を短く整理する。‘durable execution’ (永続実行) は 2020 年代初頭に Temporal が初めて大衆化した用語で、長時間実行されるワークフローの各ステップの結果を永続ストレージにチェックポイントし、途中で障害が起きても最後に成功したステップから再開できるようにするパターン を指す。ビデオゲームのセーブポイントのアナロジーがほぼ正確だ。ゲームが強制終了されても最後のセーブポイントから再開できるように、ワークフローのコードが OS / コンテナ / ノード単位で死んでも再開できる。
このパターンがなぜ高価なインフラになったか。決済処理、配送追跡、ML パイプライン、会計締めなどの作業はいずれも分 ~ 時間単位で長く、途中で障害が起きたときに最初からやり直してはいけない (あるいはコスト / データ整合性の側面で非常に高価な) 種類だ。こうした作業を単純な cron + リトライロジックで書くとエッジケースが際限なく増える。Temporal, AWS Step Functions, Apache Airflow, Argo Workflows のようなツールはこのエッジケースを標準化して解いてくれる代わりに、別のオーケストレータサービス — そしてそれを運用する運用コスト — を要求する。
DBOS の主張はこの運用コストそのものへの反論だ。情緒をそのまま訳せば — “fundamentally overcomplicated” (外部オーケストレーションは根本的に過剰複雑だ)。Postgres がすでに提供するロック、整合性制約、トランザクションというツールの上で同じ保証をより単純な運用モデルで作れる、というのが核心だ。本稿はこの主張を分解する — 何が実際に同じで、何が違って、どこまで可能か。
本文 1 — DBOS の中核メカニズム: ロックと整合性制約だけで
DBOS のアーキテクチャは三つの部分で構成される。クライアントは新しいワークフローを Postgres のワークフローテーブルに 1 行挿入する。ワーカー (アプリケーションサーバー) はそのテーブルをポーリングして自身の分のワークフローをデキュー (dequeue) する。ワーカーはワークフローの各ステップを実行し、そのステップの結果を同じ Postgres にチェックポイント行として記録する。
ここで二つの標準 Postgres 機能が中核的役割を果たす。第一は 行単位のロック だ。複数のワーカーが同時に同じワークフローをデキューしようとしても、Postgres の SELECT ... FOR UPDATE SKIP LOCKED が正確に一つのワーカーだけにそのワークフローを掴ませる。記事の表現は “each workflow is dequeued by exactly one worker” (各ワークフローは正確に一つのワーカーによってデキューされる)。外部オーケストレータがワーカーに作業を分配していた責任を、データベースの行ロックが引き受ける。
第二は 整合性制約 だ。各ステップの結果行には (workflow_id, step_id) の複合一意制約がかかっている。あるステップが二度実行されて二度のチェックポイント行を書こうとすれば、二度目の試みは整合性制約で失敗する。記事の表現は “database integrity constraints to detect duplicate work” (重複作業を検出するためのデータベース整合性制約)。単一実行保証 (exactly-once execution) という分散システムの最も難しい保証を、外部の合意アルゴリズムなしにデータベースが直接保証する。
この二つのメカニズムが合わさると、Temporal の二つの中核価値 — 分散ワーカーへのワークフロー分配能力、各ステップが正確に一度だけ実行される保証 — が外部オーケストレータなしに作られる。ワーカーが死ねばそのワーカーが掴んでいたロックが解放され、別のワーカーが同じワークフローを最後のチェックポイントから引き継ぐ。記事の一行 — 「サーバーが死ねば別のサーバーがチェックポイントからそのワークフローを復旧する」 — がこの復旧パターンを要約する。
パフォーマンス面の主張も具体的だ。単一の Postgres サーバーが垂直スケールで秒間数万のワークフローを処理できる、という一行が記事の最も強い数字だ。正確には “tens of thousands of workflows per second”。さらに大きなスケールが必要なら CockroachDB のような分散 Postgres またはシャーディングへ移す、という付随陳述が続く。つまり DBOS の主張は「あらゆる規模で Postgres が十分」ではなく「ほとんどの実用規模で Postgres が十分で、より大きな規模では Postgres の拡張メカニズムが答え」だ。
ここに SQL の副次効果が加わる。ワークフロー状態そのものが標準の Postgres テーブルなので、モニタリング / アラート / デバッグがすべて SQL クエリで可能だ。記事の例示は「過去 1 ヶ月でエラーで終わったワークフロー (errored in the last month)」を一行 SQL で取り出す。Temporal の専用 UI と API を経由せず、運用チームがすでに慣れている BI ツールでワークフローを見られる、という点は運用表面積の削減だ。
本文 2 — ‘Postgres 万能論’ の限界とトレードオフ
DBOS の主張が強い分、その限界も正確に指摘する必要がある。HN の 123 コメントで登場した懐疑論を三つに整理する。
第一の限界は プル型ワーカーモデルのレイテンシ だ。Temporal のようなツールはプッシュ型だ — オーケストレータがワーカーに作業を直接送る。DBOS のワーカーはポーリング型 — Postgres を定期的にクエリして自分の分のワークフローを探す。ポーリング間隔が 1 秒なら平均レイテンシは 0.5 秒、99 パーセンタイルのレイテンシは 1 秒 + ワークフロー実行時間だ。短くレイテンシ敏感なワークフロー (対話型ユーザーフローの 1 ステップ、リアルタイム決済の認証ステップ) ではこのレイテンシが無視できない。記事が明示的に答えていないトレードオフだ。
第二の限界は ワークフローコードの決定性 (determinism) 要求 だ。すべての永続実行システムはワークフローコードが決定的でなければならない、という制約を共有する — 同じ入力で同じステップを再実行すれば同じ結果が出なければならない。時計 (time.now()), 乱数 (random()), 外部 API 呼び出しの応答などの非決定的要素はすべて「アクティビティ (activity)」または「決定論的ラッパー」で隔離しなければならない。Temporal はこの制約を SDK レベルで強制し、違反すれば明確なエラーを投げる。DBOS の記事はこの制約をどう強制するかを短くだけ言及し、実際の使用時にどんなガードレールがあるかは文書に欠ける。SDK の精緻さは結局ツールの成熟度の測定値で、その測定値において Temporal の 7 年のサイクルが作った差がある。
第三の限界は モニタリング・可観測性 (observability) の欠如 だ。記事が誇る “SQL でモニタリング” の裏側は、Temporal の UI が提供するワークフロー実行グラフ、ステップ別タイムライン、リトライの可視化、シグナル / クエリ API などの運用ツールが欠落していることだ。運用チームがすでに慣れているツール (Grafana, Datadog) に SQL で統合できる点は長所だが、ワークフロー自体のビジュアルデバッガが必要な瞬間にその欠席が露呈する。DBOS がこの領域のツールを整えるのは時間の問題かもしれないが、現時点での限界だ。
この三つの限界を合わせると、DBOS の本当の市場は「Temporal の全機能が必要ではない中規模作業」だ。決済の後処理、バッチ ETL、会計締め、ML 学習ジョブのような領域で — レイテンシ敏感ではなく、ワークフロー数が秒間 1 万未満で、運用チームが Temporal の専門性を備えていない — Postgres 万能論はまさに正しい答えだ。
HN コメントの一行がこの位置を正確に指す — 情緒の要約 — 「Temporal を運用するほどのワークフローボリュームを持たない会社が以前はエッジケース満載の cron スクリプトで解いていた領域を、DBOS が適切なツールで埋める (DBOS fills the appropriate-tool space for companies whose workflow volume doesn’t justify operating Temporal)」。これは Temporal の席を奪うのではなく、Temporal が届かない場所に新しい標準を作る位置だ。
本文 3 — ‘単一データベース万能論’ の時代精神
DBOS の登場が単一の事件ではなく、より大きな流れの一つのシグナルである点が本稿の最後の分析だ。過去 5 年間、インフラカテゴリで類似の「データベース上の万能論」が繰り返し現れた。
第一の事例は River, Oban, pgmq — メッセージキューを Postgres のテーブル + SKIP LOCKED で実装するライブラリだ。Kafka や RabbitMQ が提供していたメッセージキューの本質をデータベースの標準機能の上に乗せて、運用すべき別システムを減らした。
第二の事例は PostgREST, Hasura, Supabase — REST / GraphQL API を Postgres のスキーマ + RLS (Row Level Security) の上で自動生成するツールだ。別の API サーバーを運用せず、データベースの権限モデルを API の権限モデルとして直接公開する。
第三の事例が今回の DBOS の 永続実行 だ。ワークフローエンジンをデータベースのロック + 整合性制約の上に乗せて、別のオーケストレータの運用負担をなくす。
三つの事例に共通するパターンは 「運用表面積の統合」 (consolidation of operational surface) だ。会社が運用すべきシステムの種類を減らし、その減った分の運用人員 / モニタリングツール / 障害対応手順を統合する。クラウド時代初期 (2010 年代) の流れが「専門ツールへの分化」(メッセージキューは Kafka, ワークフローは Airflow, 検索は Elasticsearch) だったとすれば、2020 年代中盤の流れはその逆方向 — Postgres の上に再び束ねる — だ。
この統合の流れを可能にした技術的前提が二つある。第一に、Postgres 自身の成熟。行単位ロックの SKIP LOCKED, JSONB のインデックス化, 部分インデックス, トリガーの安定性 — これらすべてが 2020 年代になってプロダクション級の信頼性に達した。第二に、クラウド管理型 Postgres (RDS, Cloud SQL, Neon, Supabase) の普及。自前 Postgres 運用の負担が事実上 0 に近くなり、それが「Postgres の上にすべて」の経済的合理性を作った。
しかしこの流れの果てがあらゆるワークロードの Postgres 一本化ではない。本当の大規模 (秒間数十万メッセージ、ペタバイト級データ、マルチリージョン整合性) では依然として専門ツールが答えだ。DBOS の位置はその両極端 — 手作り cron と Temporal — の間の空白を埋めるものであり、両極端を置き換えるものではない。この空白の大きさが — 会社数で見れば — 両極端を合わせたよりも大きい可能性がある、というのが流れの本当の含意だ。
結論 — ‘十分良いもの’ の政治学
DBOS の記事が HN の 289 点を集めた本当の理由は単純な技術自慢ではない。それは 「専門ツールの運用負担」と「単一データベースの運用シンプルさ」の間で後者を再び選べる可能性を示した ことだ。過去 10 年、インフラエンジニアは「ちゃんとやるなら専用ツールを運用せねばならない」という圧力の下にあった。DBOS はその圧力への一行の応答だ — 「十分良いもの (good enough) は十分良い」。
この応答が実務者に投げかけるメッセージは二つに分かれる。第一に、新しいワークフローシステムを設計するとき Temporal / Airflow / Step Functions をデフォルトとして選ばず、自身のワークフローの実際の要求 — レイテンシ、スループット、決定性、可観測性 — を明確に測定し、その測定値が Postgres 万能論の限界内に収まるかをまず見る。収まれば運用コストの 1 単位がまるごと消える。
第二に、すでに Temporal / Airflow を運用中ならば、その運用のどの部分が本当に価値を生むかを切り分ける。ワークフローの 95 % が単純で 5 % だけが本当に複雑なら、95 % を Postgres の上に移し 5 % だけ専用ツールに残すことが運用負担の本当の削減だ。すべてのワークロードに同じツールを使う一貫性はコストを下げているように見えるが、実際には最もシンプルなワークロードに最も高価な運用を強いる。
最後に一つの問いを投げかけて閉じる。我々が今運用しているインフラの中で、「ちゃんとやるならそうすべき」という圧力で導入したが実際の要求ははるかにシンプルだったシステムは何個あるか。そのシステムを単純なデータベース上の実装に戻せるなら、運用表面積はどれほど減るか。DBOS の本当の価値はその問いを再び問う資格を我々に与えることだ。
出典: