DBOSは、Postgresのキューが1秒あたり30,000件のワークフローに達する可能性があると述べている

Why it matters

DBOS is testing whether developers can collapse queues, workflow recovery, and application state into Postgres. Its vendor-published benchmark reports high throughput under a defined no-op workload while exposing the hardware, partitioning, and database limits operators must consider.

DBOS の共同創業者 Qian Li と Peter Kraft は、ロック、トランザクション分離、およびインデックスに対する変更を行った結果、Postgres をバックエンドにしたキューで 約30,000のワークフロー実行/秒 に到達したと述べています。この成果は彼らの大きな賭けを支持するものです：開発者は別個のキューイングやオーケストレーションサービスを追加せずに耐久的なジョブを実行できる、という主張です。

Li と Kraft はその知見を 6月2日付のエンジニアリング投稿 で公表しました。彼らの作業はスループットが増加するにつれて順に現れる三つのボトルネックを特定しました：同じ行を巡るワーカー間の競合、並行実行下で繰り返し中断するトランザクション、そしてデータベースの CPU を消費するインデックスです。

このプロジェクトは両創業者による長年のデータベース研究に続くものです。Li は北京大学で学士号を取得した後、Stanford で効率的かつ信頼性の高いクラウドコンピューティングに焦点を当てたコンピュータサイエンスの博士号を取得しました。彼女のスタンフォードでの研究には、商用製品の基盤となった学術的な DBOS プロジェクトが含まれます。Kraft は Harvard でコンピュータサイエンスを学んだ後に Stanford の博士課程に進み、以前は Google のステートフルサービス向けシャーディングシステムである Slicer に携わっていました。

彼らは Turing賞受賞のデータベース研究者 Michael Stonebraker と共に DBOS を構築しました。MIT は Stonebraker を Postgres や Ingres の背後にいる創作者またはアーキテクトとして紹介しています。Stonebraker は Vertica を含むデータベース研究を繰り返し企業化しており、MIT によれば Vertica は Hewlett-Packard に 3.4 億ドルで買収されました。

三つのボトルネックと三つの対処策

最初の問題は予測可能でした。最も古いジョブを同じテーブルから取得しようとする複数のワーカーが同じ行を選択し、多くのワーカーが一つのワーカーだけが主張できる作業を巡って競合することになります。

DBOS はその競合に対して FOR UPDATE SKIP LOCKED を用いて対処しました。このクエリは選択した行をロックし、他のワーカーにそれらの行をスキップするよう指示するため、各ワーカーが異なるバッチを取得できるようになります。公式の PostgreSQLのドキュメント は、複数のコンシューマがキュー様のテーブルにアクセスする場合に SKIP LOCKED がロック競合を防ぐことができると述べています。

DBOS は、ロッキングパターンを用いない場合、キューのスループットが概ね 100 ワークフロー/秒を超えられなかったと述べています。この改善は、約 1,000 ワークフロー/秒付近で顕在化する二つ目の制限を露呈しました。その時点で、多くの dequeue トランザクションがシリアライズエラーで失敗し始めたのです。

これらのトランザクションは REPEATABLE READ で実行されており、これはワーカーに全ワーカー間で動作中のワークフロー数の最大値などのグローバルな制限を強制するために必要な安定したスナップショットを与えていました。PostgreSQL のトランザクション分離に関するドキュメント は、REPEATABLE READ を使用するアプリケーションはシリアライズ失敗後にトランザクションを再試行する準備をしておく必要があると述べています。

Li と Kraft は、大規模なキューはしばしばグローバルな調整ではなくワーカー毎の制限に依存していることを発見しました。DBOS はグローバルフロー制御を用いるキューについては REPEATABLE READ を維持し、その他のキューは READ COMMITTED に移行しました。READ COMMITTED は PostgreSQL がデフォルトの分離レベルとして文書化しているもの です。DBOS は、この条件付きアプローチがテストにおけるシリアライズ失敗を解消したと述べています。

概ね 8,000 ワークフロー/秒 を超えたあたりで次の制約は CPU になりました。DBOS は負荷をワークフローステータステーブルの二次インデックスに起因すると特定しました。各 enqueue、dequeue、完了操作がインデックス付きデータを変更し、autovacuum が不要なエントリを消去しなければなりませんでした。dequeue クエリに使われるインデックスは次に処理すべき仕事を選ぶための優先度やタイムスタンプ順を返しておらず、Postgres によって結果をソートさせる必要がありました。

DBOS の三つ目の対処は、CPUへの圧力が dequeue クエリのコストと autovacuum／インデックスのメンテナンスに起因することを突き止めた後、二次インデックスをより選択的にし、dequeue クエリにより密接に一致するようにしたことでした。

30,600 という数値が何を測っているか

DBOS の見出しとなるスループットはベンダー公表のベンチマークです。2026年4月23日のベンチマーク報告 において Kraft は、DBOS がテストを 96 仮想 CPU、384 GB メモリ、120,000 プロビジョニング済み IOPS を備えた単一の AWS RDS db.m7i.24xlarge インスタンスで実行したと述べています。ワークロードはステップを持たない no-op ワークフローで、アプリケーションの処理時間ではなくオーケストレーションのオーバーヘッドを測るために複数の非同期 Python クライアントから同時に開始されました。

DBOS は 単一キューで最大 12,100 キューイングされたワークフロー/秒に達した と報告しており、その時点でキュー先頭の競合が制限要因になりました。DBOS は 複数キューまたは同じキューの複数パーティションに作業を分散させることで 30,600 キューイングされたワークフロー/秒に到達した と述べています。その時点で DBOS は、コミットされた書き込みが通過しなければならない Postgres のライトアヘッドログをボトルネックとして特定しました。

6月2日の投稿では、DBOS の最適化された Postgres バックエンドのキューイング経路が 数千台のサーバー上で約30,000ワークフロー実行/秒に到達した と述べられています。提示された研究には独立した再現は含まれておらず、no-op ワークロードはジョブが実質的な処理を行うアプリケーションに対する一般的な本番上限を示すものではありません。

これらの条件を踏まえると、この結果は独立して検証されたベンチマークというより DBOS のエンジニアリング上の主張として読むのが最適です：適切なロッキング、分離レベル、およびインデックスの選択があれば、DBOS は多くのチームが専用サービスに移すであろうキューのワークロードを Postgres が担えると主張しています。

ベンチマークのコードは DBOS の GitHub 組織下で公開されています（benchmark code は公開されている）。DBOS は Python、TypeScript、Go、Java 向けの個別のオープンソースライブラリも維持しています。開発者はライブラリを Postgres に接続し、通常のアプリケーションコード内でワークフローやステップに注釈を付けます；DBOS は実行状態を記録するため、プロセスの障害、再起動、再デプロイ後に中断された作業を再開できます。

ベンチマークの背後にあるインフラの賭け

DBOS はアーキテクチャの統合を売りにしています。専用のスタックは一般に RabbitMQ と Celery を組み合わせるか、Redis と BullMQ を組み合わせることが多く、Temporal のようなワークフロープラットフォームは別個のオーケストレーションサービスを運用します。DBOS は、Postgres にアプリケーション状態とワークフロー実行状態の両方を保持させることで、開発者がデプロイおよび運用しなければならないシステムの数を削減したいと考えています。

そのアプローチには明白な境界があります。十分に大きなキューは依然としてデータベースを飽和させる可能性があり、DBOS 自身のマルチキューのベンチマークはライトアヘッドログでその点に達しました。Li と Kraft の主張は、多くのアプリケーションにとってその上限は十分に高い、ということです。

DBOS は 2024年3月に Engine Ventures と Construct Capital が主導し、Sinewave と GutBrain Ventures が参加した中で $8.5 million のシードラウンド を発表しました。DBOS はその後、モデル駆動型ソフトウェアがより多くの長時間実行ジョブ、外部 API 呼び出し、リトライ、人間による承認ステップを生むにつれて、製品表現を耐久的な AI エージェントへとシフトしています。

7月16日の Cockroach Labs とのウェブキャスト は、Stonebraker のデータベース命題をまさにその新しいワークロードに直接対峙させました。キューベンチマークはそのプレゼンテーションの下支えとなるエンジニアリングの議論を提供します。Li と Kraft は、多くのアプリケーション内に既に存在するデータベースが、彼らのエージェント、バックグラウンドジョブ、および耐久的ワークフローのリカバリと調整レイヤーにもなり得ると賭けています。