堅牢なワークフロー構築の決定版：SQLiteさえあれば他には何もいらない

複雑な分散システムや外部データベースに依存していませんか？実は、堅牢で信頼性の高いワークフローを実現するために必要なのは、シンプルかつパワフルなSQLiteだけかもしれません。軽量でポータブル、そしてACID準拠のSQLiteを活用することで、オーバーヘッドを最小限に抑えつつ、堅牢なデータ処理パイプラインを構築する方法を解説します。

Temporalを使ってワークフローの構築を始めたところ。比較的軽量なローカルアプリとしてデプロイできるし、独立したローカル環境ならSQLiteを使ってくれる。APIの再試行処理やワークフロー、タスクの整理がものすごく楽になるからおすすめ。哲学的にはこの記事が言っていることそのものだけど、エージェントが利用するための非常にリッチで柔軟なインターフェースが追加される感じ。それにWeb UIのおかげでワークフローの確認やエージェントの実行履歴のチェックも簡単。Temporalはシステムに高い信頼性をほぼコストゼロで組み込んでくれる。分散型の信頼性の高いシステムを作るのは大変だし、車輪の再発明はするなってことだね。もしSQLiteのデータベースを簡単にのぞき見たり、ワークフローで何が起きているか把握したり、個別のタスクを構成したり、ワークフローを呼び出し可能にしたりしたいなら、一度Temporalをチェックしてみるといいよ。それから、自分はエージェント用にファイルを使うのはほとんどやめた。MarkdownやJSONもいいけど、小規模なローカルアプリを作るときは罠になりがち。LLMはSQLiteとの相性が抜群で、そこから何でも（MarkdownでもJSONでも）出力できる。エージェントがjqを走らせたりgrepでMarkdownを検索したりする代わりに、特定の行をクエリするだけで済むからトークンの節約にもなる。構造化されていないファイルよりも、エージェントがデータ構造を規律正しく扱えるような、持ち運び可能で自己完結型の優れたデータ管理システムが手に入るよ。小さなローカルプロジェクトが成長したり、より正式な形が必要になったりしても、MySQLやPostgresにスケールアップできるし、すでにデータに関するスキーマや規律ができているから移行もスムーズ。

SQLiteはPostgresと比べても、シングルノードのアプリケーションなら驚くほど高性能だよ。Postgresはメモリをかなり食うし、IPCを介するためにIOが必要になるけど、SQLiteなら共有コネクションプールを使ってすべてをプロセス内に留めておけるからね。エージェント用ハーネスでいろんなストレージエンジンをテストしてるけど、SQLiteなら1つのvCPUで最大7.5kの同時セッションを処理できる。Postgresだとクラッシュするか、コネクションが枯渇しちゃうんだ。[0] https://github.com/impalasys/talon/pull/23#issuecomment-4577660216

本番環境のアプリでSQLiteに固執する理由が理解できない。SQLiteは埋め込み型データベースであって、同時実行制御を管理するのには全く向いてないでしょ。そういうのはPostgresやMySQLみたいなデータベース「サーバー」の役割。複数のプロセスや別のマシンから同時にデータを変更できるようにするのが、彼らの仕事なんだから。これはコンピュータサイエンスの基本原則。どうも「何でもSQLite」派の人たちは少し経験不足なんじゃないかな。

Litestreamの5.9以降のリリースには、インスタンスが異常な量のデータを同期してしまうバグがあるよ。10KB未満のデータしか入ってなくて、読み書きもほとんどないDBなのに、1日あたり10GBものレプリケーション通信が発生するんだ。個人の趣味プロジェクトには無駄に高コストすぎて困ったよ。

「耐久性のあるワークフローにはログさえあればいい」という考え方の、次のイテレーションを見るのが待ち遠しいね。

ファイルとマルチパーティションのデータベースの間には大きな隔たりがあるよね。本番環境で使うような代物をコンテナでデータベースを動かすのは自分には合わないかな。個人的には、多くのETL処理はエンタープライズ向けのデータベースを持ち込まなくてもローカルで十分さ。そういうケースなら、DuckDBはSQLiteより5〜10倍優れているし、専用のPostgresを立ち上げるよりはるかにシンプルで高速。一般的なスクリプトなら、20行のawkスクリプトよりも、DuckDBベースのSQLスクリプトの方がきれいで堅牢だし、メンテナンスもしやすい。MotherDuckがIPOのために変な動きをしないことを願うよ。ありふれた企業の強欲さのせいでそのツールが失われたら悲しいからね。

長年SQLiteについて読み漁ったあと、個人プロジェクトで実際に使い始めたんだけど、Postgresに慣れている身からすると型システムの貧弱さにショックを受けたよ。本当に劣っていると思うし、なんでこんなに称賛されているのか分からない。https://sqlite.org/datatype3.html https://www.postgresql.org/docs/current/datatype.html 日付や時刻の扱いは30年前のデータベースを使っている気分になるし、インサート時に何も強制されない。なぜこんなに人気があるのか、誰か本当に教えてほしい。

非クリティカルなセクションで状態を保持する必要があるアプリや、SQLを使うのが実は良いアイデアだと気づいた場合（クリティカルなセクションであっても）、SQLiteは良い選択なだけじゃなく、脆いカスタムソリューションを考える時間を大幅に節約してくれるよ。インメモリのSQLite DBを維持してSQLコマンドで操作すればいいし、アプリを再起動しても状態を保持したいなら、定期的にディスクに保存したりロードしたりすればいいんだ：https://www.sqlite.org/backup.html#example_1_loading_and_saving_in_memory_databases これ、実はこれまで使った中で一番便利なファイルフォーマット（アプリケーションフォーマット）なんだよね。

大手Postgresクラスタをあちこち使っていた環境からSQLiteに乗り換えたよ。今は月間アクティブユーザー数が7桁の規模だけど、すべてSQLiteの耐久性オブジェクトでバックアップしている。アクセスパターンについては考え方を変える必要があったけど、それに見合うだけのメリットがあったよ。

このサイトが示しているプロジェクトのGitHub統計、正気じゃないよ。たった一人の著者が、ここ1ヶ月で平均して週あたり約2万行のコードを書いているんだ。一人でどうやってメンテナンスしてるんだろう？