SQLiteがあれば、耐久性のあるワークフローが実現できる

元記事: 2026年5月30日原文(obeli.sk)

概要

DBOS は耐久性実行にPostgresだけで十分と主張
一部のシステムでは SQLite でも十分な耐久性実現が可能
Litestream によるS3互換ストレージへのバックアップで可搬性を強化
AIエージェントや実験的ワークフローに最適な構成
高可用性や共有スケールが必要な場合は Postgres 利用推奨

Postgres不要論からSQLite活用論へ

DBOS は、耐久性実行において Postgres があれば追加のオーケストレーション層は不要と主張
筆者はこの方向性に賛同し、さらに進めて SQLite でも十分なケースが多いと提案
多くの耐久性システムでは、本質的に必要なのは ワークフロー状態の保存 のみ
計算リソース は安価で使い捨て可能な設計が望ましい
Obelisk のようなシステムでは、進捗は実行ログに記録され、履歴から再実行やリトライが容易
最も重要なのは ワークフロー状態の持続性と可観測性

SQLiteが適している理由

SQLite は トランザクショナルな耐久性 をローカルで実現
別途データベースサービスやネットワーク経由の制御面が不要
ローカルファイル で完結するため、運用負荷やコストを低減
多くのシステムにとって ローカルDBファイル が最適な機構

Litestreamによる可搬性向上

実験やデータが蓄積する場合、 SQLiteファイルの管理 が課題
Litestream を利用することで、 SQLiteの変更を非同期でS3互換ストレージへ転送 可能
実行環境に近い状態で作業しつつ、バックアップや移行、検証も容易
非同期レプリケーション のため、直近の書き込みが失われるリスクあり
高可用性が必須な用途には向かないが、多くのAI・実験ワークフローには十分

エージェント型システムにおける利点

AIエージェント や 自動生成ワークフロー に最適
各エージェントやテナントごとに 小規模で独立した状態管理 がしやすい
マイクロVMやコンテナ で小さなサーバー群を構築し、各自SQLite＋オブジェクトストレージバックアップ運用
常時稼働の大規模共有システムよりも シンプル・低コスト・障害分離性 が高い

Postgresを選ぶべきケース

SQLite が全てのケースに適しているわけではない
Obelisk は Postgres もサポート
高可用性 や 大規模共有スケーラビリティ が必要な場合は Postgres が適切
オブジェクトストレージへの 非同期レプリケーション では不十分な場合も Postgres 推奨
多くのワークフローシステムは初期段階で過剰なインフラを持つ必要はない
多くのケースでは SQLite＋Litestream＋安価なワーカー で十分な耐久性システムを構築可能

まとめ：AIエージェント時代の新しいデフォルト

AIエージェント や 実験的システム では、 SQLite＋Litestream 構成が最も合理的な選択肢
必要最小限のインフラで 耐久性・可搬性・運用効率 を両立
状況に応じて Postgres との使い分けが重要

提供: ハクソク · 要約更新: 2026年5月30日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

Temporalを使ってワークフローの設定を始めたんだ。ローカルアプリとしては比較的軽量でデプロイできるよ。孤立したローカルインストールにはSQLiteを使ってる。APIのリトライやワークフロー、タスクの整理がすごく簡単になるんだ。ぜひ試してみてほしい。哲学的には、この記事が提案していることそのものだけど、エージェントが使うための非常にリッチで柔軟なインターフェースが追加されてる。さらに、ウェブUIがあって、ワークフローの確認やエージェントの実行状況を見たりするのがすごく簡単なんだ。Temporalはシステムに高い信頼性をほぼ無料で組み込んでくれるし、分散型で信頼性の高いシステムを作るのは難しいから、わざわざ車輪を再発明する必要はないと思う。SQLiteデータベースを簡単に調べたり、ワークフローの状況を把握したり、個別のタスクを組み合わせたり、ワークフローを簡単に呼び出せるようにしたいなら、Temporalをチェックしてみて。あと、エージェント用にファイルからはほとんど離れた感じ。MarkdownやJSONは素晴らしいけど、小さなローカルアプリを作る時には罠に感じることもある。LLMはSQLiteに強いし、MarkdownやJSONなど、好きなものを出力できるよ。エージェントが特定の行をクエリするだけで済むから、jqやgrepを使うよりもトークンをかなり節約できる。ファイルの束よりも、データの構造をきちんとするようにエージェントを促す、ポータブルで自己完結型のデータ管理システムが手に入るんだ。それに、もしローカルプロジェクトが成長したり、もっと正式になったりしても、MySQL/Postgresにスケールアップできるから、すでにデータのスキーマや規律が整ってるよ。

└

SQLiteを使う例を、jqやMarkdownをgrepする代わりに教えてくれない？

└

これ、Temporalの広告みたいだね :)

└

ファイルとデータベースのアプローチについて面白いね。いろいろ考えた結果、データベースに落ち着いたよ。

└

HNでの噂では、temporalのマネージドソリューションに予想以上のお金を払っているか、非常に重いシステムを自分で運営するためにかなりの運用負担を抱えているらしいね。私はどちらも経験していないからわからないけど、あなたや他の人の経験からもっと知りたいな。

SQLiteは、Postgresと比べてもシングルノードアプリケーションに対して驚くほどパフォーマンスがいいよ。Postgresはもっとメモリを消費して、IPCを通るためにIOが必要だけど、SQLiteなら共有接続プールでプロセス内に全てを保持できる。エージェントハーネスのためにいろんなストレージエンジンをテストしてるけど、SQLiteなら単一のvCPUで最大7,500の同時セッションが可能なんだ。Postgresはクラッシュしたり、接続が枯渇したりするけどね。

└

SQLiteは、Postgresと比べてもシングルノードアプリケーションに対して驚くほどパフォーマンスがいいよ。SQLiteがかなり優れたソフトウェアだと理解されている文脈では、そう期待すべきじゃない？シングルノードの文脈では、Postgresはオーバースペックだよ。SQLiteと競争できるとは期待すべきじゃない。これはほぼ、インメモリのHashMapをRedisとベンチマークして、理想的な条件でうまく動くことに驚いているようなものだね。

└

正しく使えば、SQLiteは実質的にプロセス内でのメソッド呼び出しみたいなもんだよ。もし障害物がランタイム、カーネル、ファイルシステム、そしてローカルのNVMeストレージデバイスだけなら、ホスティングされた代替品よりも圧倒的にパフォーマンスが良いことに気づくかも。スレッドを離れると、レイテンシの面で負けちゃうからね。SQLiteは、スレッド間通信を強制しなければ、マイクロ秒単位で動作できるよ。

本当に、実際のプロダクションアプリでSQLiteにこだわる理由がわからない。SQLiteは埋め込み型データベースで、同時実行性を管理するには全く向いてない。これがデータベースサーバー、例えばPostgresやMySQLの役割なんだ。彼らの仕事は、異なるマシンで複数のプロセスからデータを同時に変更できるようにすることだよ。これはコンピュータサイエンスの基本原則だと思う。「SQLiteで何でも」という人たちはちょっと経験不足な気がする。

└

これはコンピュータサイエンスの基本原則だこれがどうしてコンピュータサイエンスの基本原則なの？

└

あなたは、どんな種類の並行性があるか、そしてそれにどう応じるのがベストかについて、かなり限られた理解をしているみたいだね。サーバーかどうかは、この議論にはあまり関係ないよ。SQLiteは、多くの実際のワークロードにとって優れたプロダクションDBであることは広く知られていることだし。Postgresとは全然違うから、新しいスキルセットを学ぶ必要があるよ。考え方の一つとしては、SQLiteは自然に強いパーティショニングがあるシステムの部分でうまく機能するってことだね。

└

コンピュータサイエンスは、物理学が橋を作ることだけに関わるのと同じように、具体的なソフトウェアに手を出すことはないよ。「コンピュータサイエンスの基礎原則」ではないんだ。

Hacker Newsで議論の続きを見る