なぜ今SQLiteがプロダクションで使われ始めたのか - エッジ時代に変わった前提

数年前まで、SQLite は「個人プロジェクトかスマホアプリの中で使うもの」という扱いでした。それがこの1〜2年で、本番のWebサービスでも真剣に使う候補として名前が挙がるようになっています。なぜ風向きが変わったのか、昔は何がダメで、今は何が解決されたのかを、データベースを少し触ったことがある程度の方向けに整理します。結論から言うと、WALモードという仕組みの再評価 と、世界中の拠点に SQLite を置く「エッジSQLite」基盤の登場^[1][2][3] の2つが、それまでの常識を塗り替えました。

SQLiteが「軽量用途のみ」と言われていた4つの理由

長らく SQLite が本番候補から外れていたのには、はっきりした技術的な理由がありました。1つずつ見ていきます。

同時に書き込めるのは1人だけ（単一ライタ制約）

SQLite は1つのデータベースファイルに対して、書き込みを同時に行えるのは1つの処理だけです^[4]。たとえるなら、教室の黒板に書ける人は一度にひとりしかいなくて、別の人が書きたければ書き終わるのを待つ必要がある状態です。

これに対して PostgreSQL や MySQL は、複数の人がそれぞれ別の机で同時に書類を更新できるタイプのデータベースです。同時にたくさんのユーザーがデータを保存しに来るWebサービスでは、SQLite の「書ける人は一度に1人」という制約が詰まりやすく、本番では使えないという評価につながっていました。

1つのファイルだから複数のサーバーから扱いにくい

SQLite はデータベースの中身を1つのファイルに格納し、ロックという仕組みで他からの干渉を防ぎます。ロックは「いま自分が触っているから他の人は待って」という札のようなものです。

この札の管理は、同じパソコンの中なら問題なく動きます。ただ、Webサービスでよくある「アプリ用のサーバーを何台か並べる」「データベースは1台に集約する」という構成にすると、別のサーバーから札の状態を正しく見るのが難しくなります。結果として、複数台のアプリサーバーから1つの SQLite を共有する構成は推奨されてきませんでした。

データを別のサーバーに自動コピーする仕組みがなかった

PostgreSQL や MySQL には、データの中身を別のサーバーに自動でコピーしておく機能が標準で備わっています。一般に「複製（レプリケーション）」と呼ばれる仕組みで、これがあれば1台が壊れても別のサーバーで処理を続けられます。

SQLite はもともと「1台のマシンで完結するもの」として設計されていたので、こうした自動コピー機能は長らくありませんでした。落ちずに動き続ける性能（可用性）を高める手立てが乏しい、というのが本番採用への壁になっていました。

「組み込みデータベース」というイメージ

SQLite はアプリと同じプロセスの中に埋め込まれて動くタイプのデータベースです。これは「アプリのサーバー」と「データベース専用サーバー」を分けて運用する、Webの世界の伝統的な構成と発想がそもそも違います。

スマホアプリやデスクトップアプリの中で使うなら相性がいいのですが、Webサービスで「データベース専用のサーバーを立てる」という普通のやり方には素直にハマりませんでした。「SQLite はアプリ内蔵のデータベース」というイメージが定着し、本番Webサービスの選択肢として最初から外されていた、という事情もあります。

何が変わったか

ここ数年で、上で挙げた4つの理由のうちいくつかが「実用上は問題ではない」と再評価されました。順に見ていきます。

WALモードによる読みと書きの並行化

WAL（Write-Ahead Logging）は、書き込みを直接データ本体に反映するのではなく、いったん別の場所に書き出してから後で本体に反映する仕組みです。書き込み中の本体を読みに行ってもブロックされないので、読み取りと書き込みが互いに邪魔をしなくなる のがポイントです。

書き込み自体は依然として一度に1つしか走りませんが、Webサービスにおける1リクエストあたりの書き込みは数ミリ秒で終わります。仮に1書き込み 5 ミリ秒だとすると、単純計算で 秒間 200 回までは順番にこなせる ことになります^[5]。個人ブログから中規模のサービスまで、この処理量で十分まかなえるケースが大半です。

つまり「単一ライタ」は問題に見えて、実用上の頻度では困らないことが多かった、という見直しが進みました。

エッジSQLite基盤の登場

「エッジ」は世界中のあちこちに置かれたサーバー拠点を指す言葉です。ユーザーから一番近い拠点でアプリが動くと、応答が速くなります。これを SQLite で実現するサービスが、2024〜2025年にかけて相次いで実用段階に達しました。

Cloudflare D1

Cloudflare の Workers（世界中の拠点で動くサーバーレス基盤）に SQLite を組み込んだサービスです。2024年4月に正式版になり、世界中の拠点へ自動でデータの複製が配られます^[1:1]。

Turso（LibSQL）

各地のサーバーにあらかじめ SQLite ファイルの複製を置いておき、書き込みは中央のメインに転送する方式を取っています。読み取りは手元の複製で完結するので非常に速いのが特徴です^[2:1]。

LiteFS

Fly.io が提供する仕組みで、ファイルレベルで SQLite を複製します。

Litestream

SQLite の変更履歴を Amazon S3 のようなクラウドストレージに継続的に流し込むツールです。災害が起きても直近の状態に復旧できるようになります。

これらが揃ったことで「SQLite は1台だけで動かすもの」という前提自体が崩れました。クロスリージョン（地域をまたいだ）構成の PostgreSQL を別の地域から呼ぶと 30〜80 ミリ秒かかる読み取りが、Cloudflare D1 のエッジ複製なら 10 ミリ秒未満、Turso だとマイクロ秒（=1秒の100万分の1）レベルまで縮みます^[3:1]。

「ほとんどのアプリは1つのSQLiteで足りる」という再評価

書き込み速度の議論とは別に、「自分のアプリにそんなに同時書き込みが必要なのか？」という問い直しも広まりました。多くのWebアプリは月間数万〜数十万リクエスト程度で、ピークでも秒間 100 書き込みを超えません。

Ruby on Rails の v8 が SQLite を本番デフォルトの候補に格上げしたのは象徴的で、「Webアプリの大半は1台の SQLite で足りる」という発想が、フレームワーク側からも追認された形です。

それでもPostgreSQL/MySQLが向く場面

ただし、すべての場面で SQLite が選択肢になるわけではありません。次のような要件が強い場合は、これまで通り PostgreSQL や MySQL が無難です^[4:1]。

書き込みが多い処理

リアルタイムの共同編集、高頻度のイベント記録など、たくさんのユーザーが同時にデータを保存する場面では、SQLite の「同時に書ける人は1人」という制約がそのまま詰まりの原因になります。

複雑な処理を1つのまとまりとして扱いたい場面

複数のテーブルにまたがる更新を「全部成功するか、全部失敗するか」のどちらかに揃える処理を、トランザクション（一連の処理をひとまとめにする単位）と呼びます。業務システムなど、厳密な整合性が必要な場面では PostgreSQL の方が機能面で有利です。

大規模なデータ

たとえば Cloudflare D1 は、1データベースあたり10GBの上限があります。数百GB級のデータを扱うなら、もともと大きさを前提に設計されている PostgreSQL のほうが合います。

複数のライタが同時に書き込む並行制御

PostgreSQL の MVCC（バージョン管理を使って複数の書き込みを同時にさばく仕組み）や、MySQL の行単位ロックのような、同時書き込みを前提とした制御が必要なら、これらが標準で備わるデータベースを選ぶべきです。

特に LiteFS は仕組み上、書き込みが秒間 100 程度で頭打ちになると報告されています^[3:2]。書き込み速度を最優先にするなら、中央集権型のデータベース（RDBMS。リレーショナル・データベース管理システム）のほうが素直です。

まとめ

「SQLite はおもちゃ」というイメージは、エッジSQLite基盤の成熟と WAL モードの再評価で覆りつつあります。読み取りが多く、データ量が10GB前後までで、世界中のユーザーへの応答速度が効くサービス であれば、エッジSQLite は応答速度・コスト・運用のシンプルさの3つで PostgreSQL を上回ることが珍しくなくなりました。

一方で、書き込みが多い・データ量が大きい・複雑なトランザクションが必要、といった条件では、依然として PostgreSQL が有利です。要件に応じて選び分ける時代に入った、というのが現状の落とし所です。

参考文献

脚注

1. Cloudflare D1 Overview (2026-05-08 アクセス) ↩︎ ↩︎

2. Turso (tursodatabase/turso) - GitHub (2026-05-08 アクセス) ↩︎ ↩︎

3. Post-PostgreSQL: Is SQLite on the Edge Production Ready? - SitePoint (2026-05-08 アクセス) ↩︎ ↩︎ ↩︎

4. Appropriate Uses For SQLite - sqlite.org (2026-05-08 アクセス) ↩︎ ↩︎

5. SQLite vs PostgreSQL vs MySQL: Choosing the Right Database - DeployHQ (2026-05-08 アクセス) ↩︎