DBOS が『PostgreSQL = OS』という発想を提示
DBOS（Database OS）はMITとStanford発の革新的Durable Executionプラットフォームで、『PostgreSQLをアプリケーションサーバ・状態管理・実行履歴のすべてに使う』というユニークなアーキテクチャを提案します。Temporal.io・Restateと近い役割を果たしますが、専用ワーカープロセス・分散システムを必要とせず、既存PostgreSQL運用ノウハウだけで Durable Execution が実現できる点が革新的です。2024年公開・2025〜2026年に本番採用が拡大しています。
採用すべき5つのシグナル
- Temporal.io・Restateは過剰投資・専用ワーカー運用が重い
- PostgreSQLは既に運用している・運用ノウハウを活かしたい
- 長時間処理・分散トランザクション・冪等性が必要
- 新しいアーキテクチャの早期採用に興味
- TypeScript/Python中心のスタック
DBOSの主要概念
- Workflows: 関数として書く長時間処理
- Transactions: PostgreSQLトランザクション境界
- Communicators: 外部APIとの通信
- Step Idempotency: 各ステップの冪等性自動管理
- Time Travel: 過去のワークフロー再生
- Observability: PostgreSQLに全実行履歴記録
Temporal/Restate/DBOS比較
Temporal.io: フル機能・分散ワーカー・大規模実績。
Restate: 軽量・Rust製ランタイム・新興。
DBOS: PostgreSQLだけ・軽量・運用シンプル・新しい。
使い分け: 大規模Temporal・新規スタートアップRestate/DBOS・PostgreSQL中心はDBOS。
実装パターン
(1) Workflow定義: @WorkflowContext()デコレータで関数を Workflow 化
(2) Transaction: @Transaction()でPostgreSQL書き込み
(3) Communicator: 外部API呼び出しは@Communicator()でラップ
(4) Saga: 補償処理を関数で記述
(5) Cron: Workflowをスケジューラに登録
本番採用の判断基準
- 本番実績: 2024年公開・スタートアップ採用増加中
- 運用形態: PostgreSQLだけ・専用ワーカー不要
- パフォーマンス: PostgreSQL負荷次第・中規模十分
- SDK成熟度: TypeScript・Python安定・他言語は今後
- ベンダーロックイン: OSSなので移行可能
採用しない方が良いケース
- PostgreSQL以外のDB中心
- 1秒数万トランザクションの超高頻度処理
- エンタープライズ実績重視
- 専用ワーカー運用に慣れている
- 分散DB必須の規模
実装で詰まる3つの落とし穴
- Communicator境界: 外部API呼び出しを必ずCommunicator化
- PostgreSQL負荷: ワークフロー実行履歴でDB負荷増加
- マイグレーション: スキーマ変更時のワークフロー対応
30日学習プラン
- 1週目: DBOS基礎・最初のWorkflow実装
- 2週目: Transaction・Communicator・Saga
- 3週目: Cron・スケジューラ・Time Travel
- 4週目: 本番デプロイ・PostgreSQL負荷分析
関連リンク
Temporal.ioは Temporal.io深掘り、Restateは Restate深掘り、PostgreSQLは PostgreSQL深掘り を参照してください。Background Jobsは バックグラウンドジョブ設計 もどうぞ。