SQLiteとは？MySQL・PostgreSQLとの違いと使いどころを実務目線で

SQLiteって結局おもちゃなの？本番で使っていいの？ ── これがいちばん多い疑問です。結論から言うと、SQLiteは用途を選べば本番でも十分使える成熟したデータベースで、実際にスマートフォン・主要ブラウザ・OSに標準で組み込まれ、世界で最も広く使われているデータベースエンジンのひとつです。

この記事では、SQLiteを主役に、MySQL・PostgreSQLとの違いを アーキテクチャ → 並行性 → 公式の使いどころ → 最新のサーバー用途動向 → 選び方 → よくある失敗の順で、実務目線で整理します。MySQLとPostgreSQLの細かな機能差そのものはPostgreSQLとMySQLの違いで扱っているので、本記事は 「そもそもSQLiteとサーバー型DB、どちらを選ぶか」を軸にします。

SQLiteとは何か(組み込み型・サーバーレスのDB)

SQLiteは、アプリに組み込んで使う、サーバー不要のリレーショナルデータベースです。最大の特徴は、データベース全体がたった1つのファイル(例: app.db)で完結し、別途DBサーバーを立ち上げる必要がないことです。ライブラリとしてアプリのプロセス内で直接動き、そのファイルを読み書きします。

MySQLやPostgreSQLが「電話をかけて別の担当者(DBサーバー)に依頼する」方式だとすれば、SQLiteは「手元の帳簿を自分で直接開いて書く」方式です。この違いがすべての差につながります。インストールも設定もほぼ不要で、ライブラリをリンクするだけ。バックアップはそのファイルをコピーするだけ、という手軽さです。

SQLiteはリレーショナル型？ドキュメント型？

先に混同しやすい点を整理します。SQLite・MySQL・PostgreSQLは、3つともリレーショナルデータベース(RDB)です。ドキュメント型ではありません。SQLiteは「1ファイルで動く・サーバー不要」という運用スタイルが珍しいため、MongoDBのようなドキュメント型と混同されがちですが、データの持ち方(データモデル)は一般的なRDBと同じです。テーブル(行と列)にデータを入れ、SQLで操作し、JOINや外部キーも使えます。

ここで大事なのは、「組み込み型か/サーバー型か」という軸と、「リレーショナル型か/ドキュメント型か」という軸はまったく別物だということです。SQLiteは前者では「組み込み型」ですが、後者では「リレーショナル型」に分類されます。

ややこしいのは、SQLiteもJSONを扱える点です。SQLiteは json_extract などのJSON関数やJSONB型を備えており、JSONを列に入れて「ドキュメント風」に持つこともできます。ただしこれは 「JSONも格納できるリレーショナルDB」であって、ドキュメント指向DBそのものではありません。MySQLやPostgreSQLも同様にJSON型を持ちますが、本質はリレーショナルです。もう一つの特徴として、SQLiteは型の扱いがゆるい(型アフィニティ)ため、列に宣言と違う型の値も入りがちですが、これはドキュメント型だからではなく、SQLite独自のリレーショナルな仕様です。

いちばんの違いはアーキテクチャ(組み込み vs クライアント・サーバー)

3つの違いを語るとき、最初に押さえるべきは 「組み込み型か、クライアント・サーバー型か」という一点です。ここがSQLiteと、MySQL/PostgreSQLを分ける本質です。

• SQLite ── アプリと同じプロセス・同じマシンで動き、DBファイルを直接読み書きする。ネットワークを介さないため速く、単純。ただし 複数のマシンから同じDBを共有できない(ファイル共有では壊れる)。
• MySQL / PostgreSQL ── 独立したDBサーバーが常駐し、アプリは ネットワーク越しに接続する。何台のアプリサーバーからでも同じDBに接続でき、同時書き込みも並行処理できる。その代わり、サーバーの構築・運用・チューニング・認証設定が必要。

つまり、「アプリとDBがネットワークで隔てられているか」が分岐点です。SQLite公式も、データがネットワークで隔てられているならクライアント・サーバー型を選ぶべき、と明言しています。

SQLite・MySQL・PostgreSQLの比較表

MySQLとPostgreSQLはどちらもサーバー型で、この記事の軸では同じ側に立ちます。両者の細かな違い(ライセンス・拡張機能・型・全文検索など)や選び分けはPostgreSQLとMySQLの違いで詳しく扱っています。クラウドのマネージドDBまで含めた選択肢はAWSのデータベースサービス比較も参考になります。

SQLiteの並行性:WALモードでも「書き込みは1つずつ」

SQLiteで最初につまずくのが並行性です。ここを誤解すると、本番で database is locked エラーに悩まされます。ポイントは、SQLiteは同時に書き込めるのは常に1つのトランザクションだけという点です。

デフォルトのロールバックジャーナルモードでは、書き込み中は読み込みもブロックされます。これを改善するのが WAL(Write-Ahead Logging)モードです。WALにすると、読み込みと書き込みが互いをブロックしなくなり、複数の読み手と1つの書き手が同時に動けます。多くのWebアプリはWALを有効にするのが定石です。

ただし、WALでも「同時に書けるのは1つ」という制約は変わりません。書き込みは直列化され、2つ目の書き込みは待たされます。加えて、WALは同一ホスト内でしか機能しません(プロセス間で共有メモリを使うため、ネットワークファイルシステム越しには動かない)。だからこそ「複数サーバーからの共有」には向かないのです。

公式が示す「SQLiteが向く/向かない」判断基準

SQLite公式ドキュメント(Appropriate Uses For SQLite)は、判断基準をかなり具体的に示しています。時点依存の話ではなく設計の指針なので、これに沿うのが確実です。

要は、「単一マシンで完結し、書き込みの同時性がそれほど高くない」ならSQLite、「ネットワーク越しに共有し、多数が同時に書き、規模も大きい」ならサーバー型という切り分けです。Webアプリでも、個人開発〜中規模で単一サーバー構成なら、SQLiteは十分に実用的です。

サーバー用途のSQLiteは「あり」になった(2025〜2026の動向)

かつては「本番のWebでSQLiteなんて」と笑われましたが、近年は状況が変わりました。SQLiteの弱点(バックアップ・冗長化・レプリケーション)を補うツール群が成熟し、サーバーサイドでSQLiteを本番運用する構成が現実的な選択肢になっています。

とはいえ万能ではありません。高い持続的な書き込みスループットが必要な用途(高頻度ロギングやリアルタイム入札など)は、依然としてPostgreSQL/MySQLが適します。Turso経由でも持続書き込みは概ね毎秒1,000〜5,000件程度(ネットワーク律速)が目安で、多数プロセスからの大量書き込みには向きません。また LiteFSはFly.ioが積極開発を落としており(pre-1.0)、新規に選ぶならTursoやD1の方が無難、という点も押さえておきます。

どれを選ぶか(実務の判断フロー)

出発点はシンプルで、単一サーバー・読み中心・運用を軽くしたいならSQLite、複数サーバー・多数同時書き込み・大規模ならPostgreSQL(またはMySQL)です。最初はSQLiteで始め、書き込み並行性や複数サーバー化が課題になった段階でサーバー型へ移すのも、現実的な戦略です。

よくある誤解・失敗

SQLiteに関するよくある質問

SQLiteは本番環境で使っても大丈夫ですか？

用途が合えば問題ありません。単一サーバー・読み中心・書き込みの同時性が高くないアプリなら十分実用的で、SQLite公式も1日10万ヒット未満のサイトは問題ないとしています。逆に複数サーバーからの共有や多数同時書き込みが必要なら、MySQL/PostgreSQLを選びます。

SQLiteとMySQL/PostgreSQLの一番の違いは何ですか？

アーキテクチャです。SQLiteはサーバー不要の組み込み型でDBが1ファイル、MySQL/PostgreSQLは常駐サーバーにネットワーク越しで接続するクライアント・サーバー型です。ここから、複数サーバー共有の可否や同時書き込みの強さといった差が生まれます。

SQLiteはリレーショナル型ですか、ドキュメント型ですか？

リレーショナル型(RDB)です。SQLite・MySQL・PostgreSQLは3つともリレーショナルデータベースで、テーブル(行と列)にデータを入れ、SQLで操作します。MongoDBのようなドキュメント型ではありません。「1ファイルで動く」という運用スタイルが珍しいだけで、データモデルは一般的なRDBと同じです。JSON関数やJSONB型でJSONも扱えますが、それは「JSONも格納できるリレーショナルDB」という意味で、ドキュメント指向DBそのものではありません。

SQLiteは同時アクセスに弱いのですか？

読み込みは複数同時にできます。弱いのは書き込みで、同時に書けるのは常に1つです。WALモードにすると読みと書きが互いをブロックしなくなりますが、書き込み自体は直列のままです。同時書き込みが多い用途はサーバー型が有利です。

WALモードにすれば同時書き込みできますか？

いいえ。WALは 読みと書きの競合を減らすもので、複数の書き込みを並行にはしません。書き込みは1つずつ直列で処理されます。多数の並行書き込みが要るならMySQL/PostgreSQLを検討します。

SQLiteのデータはどこに保存されますか？

指定した 1つのファイル(例: app.db)に保存されます。バックアップはそのファイルをコピーするだけ、配布もファイルを渡すだけで済みます。WAL利用時は補助ファイル(wal/shm)も一緒に扱います。

SQLiteからMySQL/PostgreSQLへ移行できますか？

できます。標準SQLの範囲で書いていれば移行の負担は小さめですが、型の扱い(SQLiteは型が緩い)や関数・自動採番の差で調整が要ります。将来サーバー型へ移す可能性があるなら、SQLite独自の挙動に依存しすぎないようにしておくと楽です。

個人開発や小規模サービスならどれがおすすめですか？

単一サーバーで運用を軽くしたいならSQLiteが有力です。Litestreamでバックアップを固めれば本番でも安心して使えます。将来的に複数サーバー化・大量書き込みが見込まれるなら、最初からPostgreSQL(またはマネージドDB)にしておく判断もあります。

まとめ

SQLiteとMySQL/PostgreSQLの違いは、機能の優劣ではなく 「組み込み型か、クライアント・サーバー型か」という設計思想の差です。SQLiteは1ファイルでサーバー不要、単一ホスト・読み中心で真価を発揮し、MySQL/PostgreSQLはネットワーク越しの共有と高い同時書き込みに強い。判断軸は「複数サーバーで共有するか」「同時書き込みが多いか」「規模はどれくらいか」の3つです。近年はLitestreamやTursoでサーバー用途のSQLiteも現実的になったので、小さく始めてSQLite、スケールが必要になったらサーバー型という選び方が、今の実務にはよく合います。

参考リンク

• SQLite: Appropriate Uses For SQLite(公式の使いどころガイド)
• SQLite: Write-Ahead Logging(WALモードの公式解説)
• PostgreSQL: 公式サイト
• MySQL: 公式サイト