SQLiteを唯一のデータベースとして使用する - 本番環境向けチューニングの実践ガイド

フィールドガイドでは、埋め込みSQLiteが実運用の負荷に耐えられることを主張しています。そのためにはWAL/mmap/VFSの設定（knobs）を理解する必要があります。その裏側や、解決できないトレードオフについても解説します。

簡単に言えば。新しい技術記事が、アプリ内に組み込まれたデータベースであるSQLiteが適切に設定すれば実用的な本番ワークロードに対応できることを主張しています。同記事では、SQLiteを低レイテンシのサーバーバックエンドに変える、pragma、ジャーナリングモード、仮想ファイルシステム層について解説しています。

コンテキスト

同記事「SQLite in Production: Optimizing WAL Mode, Concurrency, and VFS Layers for Low-Latency App Servers」（micrologics.org、2026年7月29日）は、実務者向けの設計図として読むことができます。同記事は、Postgresを無意識に選択してしまうチームに向け、DBへのネットワークホップが本当にコストの低い選択だったのかを問い直す内容です。

内部の仕組み

主に3つの要素が機能を支えています。

WALモード。PRAGMA journal_mode=WAL;はロールバックジャーナルを-walファイルに置き換えます。リーダーとライターがページキャッシュ上で互いにブロックすることがなくなり、ライターのみがシリアライズされます。注意点として、放置するとWALファイルが肥大化します。そのため、PRAGMA wal_autocheckpointやアプリからの明示的なPASSIVE/FULL/RESTART/TRUNCATEコールによるチェックポイント戦略が必要です。

競合の形状。SQLiteはシングルライターのエンジンです。同記事のベースラインでは、PRAGMA busy_timeout = 5000;で自動リトライを行い、BEGIN IMMEDIATE;で書き込みを行うトランザクションを開始します。これにより、2つのBEGINが競合する際の古典的なデッドロックを回避します。

メモリ。PRAGMA cache_size = -64000;（64 MB）とPRAGMA mmap_size = 1073741824;（1 GB）により、ほとんどの読み取りがポインタ演算に変わります。

分析

同記事の価値はpragmaにあるのではなく、SQLiteのVFSがアーキテクチャを変える拡張ポイントであるというフレーミングにあります。Litestream（S3への非同期レプリケーション）やLiteFS（FUSEベースの分散レイヤー）は、ローカルファイルという前提を、クエリコードを変更することなくネットワーク耐性のあるものに変えます。エフェメラルなクラウドディスクでは、VFSレイヤーこそが設計の対象であり、pragmaではないのです。

同記事が認めるトレードオフ

明確な限界：数テラバイトのデータセット、地理的に分散した書き込み、多数のライターにまたがる真のMVCCを必要とするワークロード。これらの限界を下回る場合、同記事は運用面がマネージドPostgresよりも小さく、p99レイテンシがソケット往復ではなくメモリコピーであると主張しています。

結論

テナントごとのブロブが「データベース」であり、ホットパスが1〜5 msであるAI時代のバックエンドを構築するチームにとって、もはや疑問は「なぜSQLiteを本番で使うのか」ではなく「どのVFSを使うのか」です。同記事は、main.goの横に貼り付けるチェックリストとして読むのが最適であり、クラスターを廃止できるという約束ではありません。