SQLite で Durable Workflows は十分なのか — Obelisk が示す Temporal の代替像

はじめに

「Durable Workflows には Temporal が必要」という常識に、SQLite ひとつで挑むブログ記事が Hacker News で 648 ポイントを集めた。Obelisk プロジェクトが公開した「SQLite is all you need for durable workflows」は、DBOS 社の「Postgres があれば十分」という主張をさらに一段進め、多くのシステムでは SQLite で永続ワークフローは完結すると論じる。本記事では Obelisk の提案を起点に、Durable Execution の最小構成がどこまで縮められるのか、Temporal や Cloudflare Dynamic Workflows との位置関係をエンジニア視点で整理する。

Durable Workflows とは — Temporal が解いている問題

Durable Workflow（永続ワークフロー）は、プロセスが落ちても・サーバーが再起動しても・ネットワークが切れても、ワークフローの進捗が失われない実行モデルを指す。代表格の Temporal は event sourcing + idempotent execution の組み合わせでこれを実現する。ワークフローの各ステップの入出力をイベントログに記録し、障害時にはログを再生して直前の状態を復元する。State machine を自前で書かなくて済むため、リトライ・タイムアウト・補償処理といった分散システムの面倒事をビジネスロジックから分離できるのが売りだ。

ただし Temporal の本格運用には Cassandra か PostgreSQL のクラスタ、専用の Worker フリート、History/Matching/Frontend の各サービス群が必要になる。「分散ワークフローのために分散システムをもう一段積む」構図で、小規模プロダクトには明らかに過剰だ。この重さを問題視する流れは以前からあり、Inngest はサーバーレス前提の軽量モデルを、DBOS は「Postgres 一個で完結する」モデルを提示してきた。Obelisk の主張はこの延長線上で、そもそも Postgres もネットワーク越しに置く必要があるのかを問い直している。

Obelisk の提案 — SQLite + Litestream で何が変わるか

Obelisk は Rust 製のオープンソースワークフローエンジンで、状態の保持を SQLite に任せる。記事の核心は「耐久性の本質はワークフロー状態の保持であり、計算リソースは安価で使い捨て可能」という観点だ。ワーカーは SQLite ファイルに実行ログを書き込み、Litestream が S3 互換ストレージへ非同期でレプリケートする。観測が必要なときはデータベースを直接検査すればいい。Postgres を経由するネットワークホップも、別建ての制御プレーンも、専用の運用ノウハウも要らない。

この構成が成立する理由は、Durable Workflow が要求する書き込み特性が SQLite と相性が良い点にある。append-only に近いイベントログ、トランザクション境界内での状態更新、強い一貫性。SQLite は単一プロセスでは秒間数万のトランザクションを捌けるため、テナント単位や Agent 単位で SQLite ファイルを切り分ければ、巨大な共有 DB が要らなくなる。Litestream のおかげで耐障害性も担保される。Obelisk のワーカーは Wasm コンポーネントを実行できる設計になっており、ワークフロー定義は Rust だけでなく WIT インターフェイスを満たす任意の言語で書ける。

Postgres 派との線引きも明確だ。記事は「より高い可用性、広範な共有スケーラビリティ、または非同期レプリケーション以外の耐久性モデルが必要な場合は Postgres が適切」と書く。逆に言えば、バースト的・実験的・テナント分離が支配的なワークロードでは SQLite で十分という線引きで、これは AI エージェントの実装パターンと噛み合う。

AI エージェント時代に SQLite 派が刺さる理由

このタイミングで SQLite 派の主張が刺さるのは、ワークフローの単位が「企業全体のオペレーション」から「エージェントごとの実行履歴」にシフトしているからだ。Cloudflare が 5 月に発表した Dynamic Workflows も、テナント・エージェント・リクエストごとに異なるワークフローコードを走らせる方向に舵を切っている。共有 DB に全社のワークフロー状態を集約する Temporal モデルより、エージェント 1 体ごとに小さな永続化レイヤを持たせるほうが、起動も停止も切り替えも軽い。

実装面でもメリットが揃う。マイクロ VM や Firecracker、Cloud Run のような秒課金環境では、SQLite ファイルを 1 つ抱えたコンテナを必要なときだけ起動して仕事を終えたら畳む、というモデルが組みやすい。Postgres を相手にする場合、コネクションプール・接続レイテンシ・スキーマ管理が常時オンの前提になるが、SQLite なら起動コストはファイルオープンだけ。障害分離も自然で、あるテナントの SQLite が壊れても他のテナントには波及しない。

一方で注意点もある。複数ノードでの強整合な書き込み、リーダー選出、複雑なクエリ分析といった用途は SQLite の射程外だ。Obelisk 自身も Postgres バックエンドを用意しており、「まず SQLite で始め、必要になったら Postgres に切り替える」という段階的アプローチを推奨している。Hacker News の議論でも「単一ノード前提の制約をどこまで受け入れるか次第」という声が多かった。Durable Execution の問題領域そのものが Temporal 一強ではなくなり、用途別に選択肢が広がっているのが今の状況だ。

エンジニアへの影響 — どこから SQLite 派を試すか

実務での導入を考えるなら、入り口は 新規のサイドプロジェクト か AI エージェントのバックエンドだ。Temporal を入れるほどの規模感ではないが、リトライ・タイムアウト・状態復元は欲しい、という典型的なギャップに Obelisk のような SQLite ベースのエンジンはぴったり収まる。CI のジョブオーケストレーション、社内向けの自動化、LLM エージェントのツール呼び出し履歴管理、いずれも単一テナント・単一ノードで十分に回せる範囲だ。

既存の Temporal を入れ替えるかどうかは別問題で、ここは慎重に判断するべきところだ。複数チームが共有しているワークフロー基盤、横断的な可観測性、複雑な親子ワークフロー連携が動いている環境では、Temporal の重さがそのまま価値になっている。記事の主張も「Temporal を捨てろ」ではなく「全てを Temporal で受け止める必要はない」という位置づけで、現実的なメッセージだ。Cloudflare Dynamic Workflows のようなマネージドサービスも視野に入れつつ、ワークロードの形状ごとに最適な Durable Execution エンジンを選ぶ、というのが今後 2026 年の標準的な設計判断になる。

まとめ

Obelisk の「SQLite is all you need」は、Durable Workflows の世界に 最小構成の選択肢を持ち込んだ提案だ。Temporal の重厚さも、DBOS の Postgres 一本構成も否定せず、その手前に「テナントごと・エージェントごとに SQLite を抱えるモデル」という第三の道を示している。AI エージェントの実装が秒単位のバースト処理とテナント分離を要求する流れの中で、この方向性は今後さらに広がる。Durable Execution = Temporal という思考停止から離れ、ワークロードの形状と運用負荷の天秤で選ぶ時代に入ったと見るのが妥当だ。

今日のその他のニュース

Claude Code Dynamic Workflows 入門（はてブ 178users） — Claude Code の新機能 Dynamic Workflows の入門解説。本ブログでも5/29 の記事で技術深掘りを公開済み。
MCP is dead?（Hacker News 361pts） — Model Context Protocol の現状評価と代替アプローチの提案。エージェント実装の選択肢が分岐する局面に来ている。
Supabase Passkeys (Beta) for Auth — WebAuthn 対応のパスワードレス認証が Supabase Auth に追加。Wrappers v0.6.0 では OpenAPI FDW も登場。