SQLite を本番環境で使用することについて：Julia Evans が実際に運用して得た知見

Julia Evans は SQLite についてのメモを公開しています：特に目新しいことはありませんが、この小さなファイルで実際のアプリを動かすことにためらっている人にとっては非常に役立つものばかりです。

具体的な事例

Julia Evans - そのZinesや記事がLinux、HTTP、DNSの内部構造についての開発者の一世代を教育してきた - は、2026年7月17日にブログ「jvns.ca」に「Learning a few things about running SQLite」という記事を公開した。これは初心者向けのチュートリアルでも、宗教的な主張でもない。SQLiteを自分のサービスに本番環境で導入した人が、驚いたことをメモしたフィールドノートだ。楽しめる内容だ。

学び

私たちは記事の内容をネタバレしない - 英語だが短いので、ぜひ読んでみてほしい - だが、SQLiteの本番環境での議論でよく出てくるいくつかのポイントを、ここでもう一度思い出しておこう。

1. WALモード：並行処理に不可欠

デフォルトでは、SQLiteはDELETEジャーナルモードを使用し、書き込みが読み込みをブロックする。WAL（Write-Ahead Logging）では、読み込みが書き込みをブロックせず、逆に書き込みも読み込みをブロックしない：

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

synchronous = NORMAL（FULLではなく）は、電源が突然切れた場合に最大で最後のトランザクションを失うことを許容し、代わりにパフォーマンスを大幅に向上させる。これは、Litestreamやほとんどの現代的なSQLiteサーバーが行っていることだ。

2. 単一の書き込み接続、複数の読み取り接続

PostgreSQLとは異なり、SQLiteは書き込みを並列化しない。RustやGoでよく見られるパターンは、単一の接続を書き込み専用に予約し、読み込み用に接続プールを作成することだ。これは、rusqliteクレートとdeadpool-sqliteの組み合わせでこの分離を行うモデル、またはGoのライブラリmattn/go-sqlite3でsql.DBをSetMaxOpenConns(1)に設定して書き込みを行うモデルだ。

3. ライブバックアップ：LitestreamまたはLiteFS

トランザクションが進行中の場合にSQLiteファイルを「コピー」してバックアップを取るのは、バックアップが破損する最良の方法だ。2つのツールが支配している：

• Litestream（Ben Johnsonによる、BoltDBの作者でもある）：S3、Backblaze B2、またはGCSに連続して複製する。WALのストリーミング、迅速な復元。
• LiteFS（同じ作者、現在はFly.ioに在籍）：さらに進化し、任意のレプリカから読み取りが可能なマルチノードレプリケーション。

4. 2026年のSQLiteの真の限界

SQLiteは、WALモードで適切にインデックス化されている場合、単一のファイルで数万のクエリを秒間で処理できる。真の限界はSQLではなく、ディスクだ：ローカルNVMe >> ネットワークディスク、EBS gp3 >> EFS。多くのSQLiteの本番環境での失敗は、ファイルをネットワーク共有（特にNFS - SQLiteはドキュメントsqlite.org/faq.html#q5で明確に推奨しない）に置いたことによるものだ。

覚えておくべきこと

Julia Evansの視点は、いつも通り、試し、測定し、見つけたことを書くだ。「SQLiteはスケーラブルだ」でも、「何か本物のものをするにはPostgresが必要だ」でもない。ただ、このような振る舞いが私を驚かせた、その理由と、私が変えたことを書いているだけだ。

単一サーバーアプリケーションやサイドプロジェクトに大規模なリレーショナルアーティラリーを導入するかどうかを悩む開発者にとって、このような記事は100の合成ベンチマークに値する。