5月29日、ワークフロー実行プラットフォームのObeliskが「SQLite is All You Need for Durable Workflows - Blog」と題した記事を公開した。この記事は、最近DBOSが提唱した「Postgres is all you need for durable execution」に対する反論として注目を集めており、AIエージェントやワークフローシステムにはSQLiteとLitestreamの組み合わせで十分だと主張している。

AIワークフローでSQLiteが有利な理由

多くのAIエージェントはバースト的で実験的な性質を持つ。LangChainやLlamaIndexを使ったAIアプリケーションでは、各エージェントやテナントが小さな自己完結した状態単位を持つケースが多く、大規模な常時稼働の共有データベースよりも軽量なアプローチが適している。

Obeliskチームは、マイクロVMやコンテナ内の小さなサーバー群で、それぞれが独自のSQLiteデータベースとAmazon S3バックアップを持つ構成を提案している。この手法には以下のメリットがある：

• シンプルさ: ネットワークホップや追加のコントロールプレーンが不要
• コスト効率: 重厚なデータベースサーバーが不要
• 障害分離: 一つのワークフローの障害が他に影響しない
• デバッグ容易性: ローカルファイルとして状態を直接検査可能

PostgreSQL vs SQLite：永続性の考え方を変える

従来、永続的な実行には永続的なインフラが必要だと考えられてきた。しかしObeliskの提案では、永続性が必要なのはワークフローの状態であり、コンピュート部分は安価で使い捨て可能なままでよいという。

最近DBOSが「Postgres is all you need for durable execution」と主張したのに対し、Obeliskチームはこの考えをさらに推し進め、多くの永続システムにとってSQLiteだけで十分だと反論している。特に開発初期段階や実験的なプロジェクトでは、過度に複雑なインフラを避けながら必要十分な永続性を確保できる。

Litestreamによる耐久性の実現

SQLite単体では単一障害点となるリスクがあるが、Litestreamを組み合わせることでこの問題を解決している。LitestreamはBen Johnsonによって開発されたオープンソースツールで、SQLiteの変更をS3互換のオブジェクトストレージに非同期でストリーミングできる。

これにより、作業状態をランタイムの近くに保持しながら、バックアップ、移行、検査のためにデータベースを簡単にコピーできる。同じファイルをローカル再生、デバッグ、エージェントの実際の動作理解に使用できるのも大きな利点だ。

注意点：非同期レプリケーションのリスク

Litestreamのレプリケーションは非同期であることに注意が必要だ。SQLiteボリュームがコピー前に消失すると、復元時に最新のローカル書き込みが失われる可能性がある。高可用性が求められる本番システムでは、この制約を慎重に評価する必要がある。

それでも多くのAIや実験的ワークフローには問題ないレベルであり、ObeliskサーバーをSQLiteデータベースで動作させ、Litestreamでバックアップし、必要に応じてオブザーバーが興味深いデータベースを取得する運用モデルが有効だ。

PostgreSQLを選ぶべき場面

もちろん、SQLiteがすべてのケースの答えではない。ObeliskはPostgreSQLもサポートしており、以下の場合はPostgreSQLが正しい選択となる：

• より高い可用性が必要
• 広範な共有スケーラビリティが必要
• オブジェクトストレージへの非同期レプリケーションでは不十分な耐久性が必要

多くのワークフローシステムは初日からそれらを必要とせず、状態が実際に要求するより多くのインフラから始めるべきではない。多くの場合、ローカルSQLiteデータベースとS3へのLitestreamバックアップで十分であり、その周りに安価なワーカーを追加すれば、非常に少ないインフラで永続的なシステムが構築できる。

AIエージェントの普及に伴い、この軽量アプローチがデフォルトの選択肢になる可能性は高い。特に急速に発展するAI分野では、迅速な実験とイテレーションを可能にするシンプルなアーキテクチャの価値がますます重要になっている。

詳細はSQLite is All You Need for Durable Workflows - Blogを参照していただきたい。