WordPressのSQLite本番運用は現実的か？表示速度と保守性から見た検証

ただし、「SQLiteだから速い」「MySQLが不要になる」と単純に考えると、早い段階でユーザーの痛みに直面する。SQLiteは読み込みには強い一方、書き込みを同時に大量処理する設計ではない。記事の表示速度だけを見て採用すると、管理画面、コメント、予約投稿、プラグインの更新処理で挙動が変わる。

WordPressのSQLite本番運用を検討するなら、見るべき指標はページの表示速度だけではない。アクセス集中時の書き込み待ち、バックアップからの復旧、プラグイン互換性、移行手順。プロダクトとして継続できるかどうかを決めるのは、むしろこの周辺だ。

SQLite Database Integrationの現在地

WordPressでSQLiteを使うための代表的な選択肢が、WordPress公式チームのPerformance Teamによって提供されている「SQLite Database Integration」プラグインだ。

このプラグインは、WordPressのデータベース層をSQLiteに対応させるためのもの。WordPress本体が最初からSQLite専用の構成になっているわけではなく、既存のデータベース接続を差し替える形で動作する。

ここは採用判断で混同されやすい。

SQLite対応の動きが公式チームで進んでいることと、WordPress本体にSQLiteが標準搭載されていることは別だ。将来的なコアでの標準サポートを目指したテストや検討は進められているが、現時点で「これからのWordPressはSQLiteが標準になる」と断言できる段階ではない。

導入に必要な前提もある。サーバー側でPHPのPDO SQLite拡張機能が有効になっていること、SQLiteのバージョンが3.37.0以降であること。この条件を満たしていない環境では、プラグインを入れただけでは動かない。

レンタルサーバーでは、PHPのバージョンを変更できても、PDO SQLite拡張機能まで利用者が制御できないことがある。ここでつまずくと、WordPressの設定以前にホスティング環境の選び直しが必要になる。

なぜ公式チームがSQLiteを検討するのか

SQLiteは、データベースサーバーを常駐させずに使える。MySQLやMariaDBのように、データベースサービスの作成、接続情報の管理、ユーザー権限の設定、サーバー間の接続を用意しなくてもよい。

個人開発では、この差が意外に大きい。

たとえば、小規模なWordPressサイトをDockerで立ち上げる場合、通常は次のような構成になる。

• WordPress用のコンテナ
• MySQLまたはMariaDB用のコンテナ
• データベース用のボリューム
• コンテナ間のネットワーク設定
• 環境変数による接続情報
• データベースのバックアップ処理

SQLiteなら、データベースサーバー用のコンテナを省略できる。設定ファイルに接続先のホスト名やポートを記述する必要もない。サイトの構成が一つのアプリケーションに近づく。

これは開発初期の摩擦を減らす。新しいテーマやカスタムブロックを試す場合も、環境を複製しやすい。小さな検証用サイトを大量に作る場合、データベースサーバーの管理から解放される効果は無視できない。

ただし、構成が単純になることと、アプリケーション全体の互換性が高まることは同じではない。SQLiteはあくまでデータベースエンジンであり、MySQLと同じ振る舞いをするわけではない。

SQLiteの価値は「WordPressを速くする魔法」ではなく、サイトを小さく始め、少ない部品で運用できることにある。

WordPressのSQLite本番運用で性能を左右するもの

「WordPress SQLite 本番運用 性能」と検索すると、データベースファイルが軽いことや、構成がシンプルであることが注目されがちだ。しかし、サイトの表示速度はデータベースの種類だけでは決まらない。

WordPressのフロントエンドでは、ページキャッシュ、オブジェクトキャッシュ、画像の最適化、テーマのテンプレート処理、外部通信、プラグインのフック処理が複合する。SQLiteへ変更しただけで、ページ全体の応答時間が劇的に改善するとは限らない。

むしろ、キャッシュが効いているサイトでは、通常のページ表示でデータベースへのアクセス回数自体が少ない。投稿ページをキャッシュしているなら、訪問者が受け取る速度はデータベースエンジンよりも、キャッシュの有無や配信経路に強く左右される。

SQLiteの評価では、次のように処理を分けて考えたほうがよい。

読み込みは小規模サイトと相性がよい

SQLiteは並列読み込みに対応している。複数のリクエストが同時にデータを読むケースでは、読み込み処理だけなら大きな問題になりにくい。

個人ブログや小規模な情報サイトでは、アクセスの中心は記事の閲覧だ。投稿一覧、固定ページ、カテゴリー、タグなど、データを読む処理が大半を占める。このタイプのサイトなら、SQLiteの特性と利用パターンが合いやすい。

特に、次の条件が重なるサイトでは検討しやすい。

• 記事の更新頻度が低く、日常的な書き込みが少ない
• 訪問者の多くが公開ページを読むだけ
• コメント機能を使わない、または限定的に使う
• 会員登録やユーザーごとの状態管理がない
• ページキャッシュを前提にしている
• データベースを利用するプラグインが少ない

この場合、SQLiteが処理する書き込みは、記事の公開、設定変更、プラグイン更新、管理画面での操作が中心になる。書き込みが連続しないため、同時書き込み制限の影響が表面化しにくい。

書き込みは一度に一つ

SQLiteの大きな制約は、書き込み処理が同時に一つに制限されることだ。読み込みは並列に処理できても、複数の処理が同時にデータベースを書き換えようとすると、後続の処理は待機する。

ここでいう書き込みは、管理者が記事を保存する操作だけではない。

• 新規ユーザーの登録
• コメントの保存
• セッションや一時データの更新
• 投稿メタデータの変更
• フォーム送信内容の保存
• 注文情報や決済状態の更新
• プラグインによる定期処理
• 検索インデックスの更新
• アクセス解析データの記録

このような処理が同じ時間帯に重なると、読み取り中心のブログとは異なる挙動になる。

たとえば、記事を読むだけの訪問者が増えても、ページキャッシュが機能していれば、データベースへの書き込みは発生しない。反対に、アクセス数がそれほど多くなくても、フォーム送信や会員機能によって一斉に書き込みが発生すれば、SQLiteの待機がボトルネックになる。

アクセス数だけでは判断できない。見るべきは、アクセスの中にどれだけ書き込み処理が含まれているかだ。

読み込み性能より「書き込みの密度」を見る

採用前に仮説を置くなら、次のようになる。

「このサイトは訪問者数が少ないからSQLiteで問題ない」

この仮説は粗い。より正確には、

「このサイトは、同じ時間帯にデータベースへの書き込みが集中しないからSQLiteで運用できる」

と置き換えるべきだ。

この違いは、個人開発のプロダクトで特に重要になる。初期のユーザー数が少なくても、ユーザーがログインし、投稿し、コメントし、検索し、状態を更新するサービスなら、書き込み密度は高い。反対に、閲覧者が増えても静的キャッシュで配信できるメディアなら、書き込み密度は低いままかもしれない。

WordPressをCMSとして使う場合も同じだ。編集者が一人で、公開前にまとめて記事を作り、訪問者は読むだけならSQLite向き。一方、複数人が同時に編集し、予約投稿やワークフローを組み、外部サービスと同期するなら、MySQLやMariaDBのほうが扱いやすい。

MySQL・MariaDBとSQLiteの違いを運用目線で見る

SQLiteとMySQL系データベースの比較は、処理速度の優劣だけで語ると失敗する。実際には、どの処理をどの頻度で行い、障害時にどう復旧するかという運用設計の比較だ。

SQLiteに優位性があるのは、構成の簡単さとデータの持ち運びやすさだ。MySQL系の優位性は、同時実行と互換性、そして長年蓄積された運用ノウハウにある。

ここで「SQLiteのほうが新しくて効率的」「MySQLは大げさ」と判断する必要はない。データベースサーバーを置くことが本当に負担になっているのか、その負担をSQLiteの互換性リスクと交換する価値があるのか。比較すべきはそこだ。

表示速度の改善を目的にするなら順番が違う

WordPressの表示速度に課題がある場合、最初にデータベースをSQLiteへ変更するのは、あまり良い仮説ではない。

先に確認したいのは、次のような部分だ。

• ページキャッシュが有効か
• 画像が必要以上に大きくないか
• テーマが不要なデータを毎回取得していないか
• プラグインがフロントエンドで大量の処理を実行していないか
• 外部APIへの接続をページ表示中に行っていないか
• データベースクエリが増え続けていないか
• 管理画面の処理と公開ページの処理を分離できているか

SQLiteに変えても、テンプレートの中で不要なクエリを繰り返していれば、問題の根は残る。重いプラグインが外部通信をしていれば、データベースを変えても待ち時間は消えない。

プロダクト改善では、施策の目的と手段を混ぜないことが基本になる。「SQLiteにする」は手段であって、「初期構築を簡単にする」「バックアップを簡略化する」「低コストで小規模サイトを運用する」が目的だ。

ファイルベース管理がもたらす保守性

SQLiteでは、データベースが「.ht.sqlite」などの単一ファイルとして保存される。この構造は、個人開発者にとって非常にわかりやすい。

MySQL系のデータベースでは、アプリケーションのファイルとデータベースが別のサービスとして存在する。サイトを移行するときは、ファイルのコピーに加えてデータベースのエクスポート、インポート、接続情報の変更が必要になる。

SQLiteでは、データベースファイルを含めてサイトの状態を把握しやすい。開発環境から検証環境へ移す場合も、ファイルを移動するという発想で扱える。もちろん、ファイル権限やパス、バックアップの整合性は確認しなければならないが、構成を頭の中で追いやすい。

これは、個人開発者にとって大きなメリットだ。

一人で開発、運用、問い合わせ対応、障害復旧まで担当していると、複雑な構成はそのまま認知負荷になる。サービスが動いている間は気にならなくても、深夜に障害が起きたとき、復旧対象が一つのファイルにまとまっていることは安心材料になる。

ただし、単一ファイルだから安全という意味ではない。

バックアップは簡単になるが、雑に扱ってはいけない

SQLiteのバックアップは、ファイルをコピーするという単純な形にできる。しかし、WordPressが稼働中に書き込みを行っているタイミングで、データベースファイルを無秩序にコピーすればよいわけではない。

バックアップで確認したいのは、次の範囲だ。

• データベースファイルが確実に含まれているか
• wp-content内のアップロードファイルも保存されているか
• テーマとプラグインのバージョンを復元できるか
• バックアップ時点のデータベースとファイルが対応しているか
• 実際に復元できるか
• バックアップファイルへのウェブアクセスを防げているか

SQLiteを導入すると、データベースの管理が簡単になる。その一方で、データベースファイルがウェブ公開領域に存在することによるリスクには注意が必要だ。

データベースファイルを直接ダウンロードされれば、サイト内の投稿、設定、ユーザー情報などが漏洩する可能性がある。プラグインの設定やサーバーのアクセス制御によって、データベースファイルへの直接アクセスを防ぐ設計が必要になる。

ファイル一つで管理できるからこそ、そのファイルをどこに置くかが重要になる。便利さと露出リスクはセットだ。

移行は「ファイルを移すだけ」では終わらない

SQLite環境ではファイル移動による移行が可能になる場合がある。しかし、既存のMySQLやMariaDBで動作しているWordPressを、簡単にSQLiteへ置き換えられるわけではない。

MySQLやMariaDBからSQLiteへ自動で移行する公式ツールは、WordPressコアに含まれていない。既存サイトを移行する場合は、新しいSQLiteデータベースを作成してデータを移すか、外部ツールを使って変換する必要がある。

ここで問題になるのは、単純なテーブルデータだけではない。

• データ型の違い
• SQL構文の違い
• インデックスや制約の扱い
• シリアライズされたWordPressデータ
• プラグイン独自テーブル
• 文字列や日付の保存形式
• 大文字・小文字の比較挙動
• 予約語や関数の違い

WordPress本体がSQLiteで動作しても、プラグインがMySQL固有のSQLを実行すれば、そこで止まる。移行の成否は、WordPress本体よりも追加機能の実装に左右される。

既存サイトの移行を考えるなら、先に本番データを触るのではなく、複製環境で一度変換する。トップページが表示されるだけでは検証として不十分だ。管理画面、投稿編集、メディアアップロード、検索、フォーム、予約処理、定期処理まで確認して初めて、移行の仮説を評価できる。

プラグイン互換性が最大の不確定要素

WordPress SQLiteのデメリットとして最も大きいのは、プラグイン互換性を一括で判断できないことだ。

「公式プラグインだから必ず対応している」「有名なプラグインだから問題ない」とは言えない。SQLite Database IntegrationがWordPressのデータベース接続を支えていても、プラグイン側がwpdbを正しく使っているとは限らない。

特に注意したいのは、次のような実装だ。

MySQL固有のSQLを直接実行するプラグイン

WordPressの標準的なデータベース操作を経由せず、プラグインが独自にSQLを組み立てている場合、SQLiteで構文エラーになる可能性がある。

MySQL専用の関数やデータ型、テーブル定義、インデックス指定などを使っていれば、SQLiteではそのまま実行できない。プラグインの画面が表示されても、保存時や検索時だけエラーになるケースも考えられる。

大量の書き込みを行うプラグイン

アクセス解析、検索インデックス、ログ記録、フォーム、会員管理などは、訪問者の操作に応じてデータベースへ書き込む。

サイトへのアクセスが少ないうちは問題が出なくても、キャンペーンや記事の拡散をきっかけに書き込みが集中することがある。ここで一つの書き込みしか許容しないSQLiteの特性が、待ち時間やエラーとして表れる。

機能が動くかどうかだけでなく、どのくらいの頻度で書き込むかを見る必要がある。

独自テーブルを作るプラグイン

WordPress本体の投稿、ユーザー、設定などを使うだけなら、対応作業の範囲を絞りやすい。一方で、プラグインが独自テーブルを作成し、複雑な検索や集計を行う場合は確認項目が増える。

インストール時にテーブルが作れるか。データが保存できるか。管理画面で一覧を表示できるか。削除や更新が正しく動くか。アンインストール時に後処理ができるか。

この一連の流れを見ずに「インストールできたから対応済み」と判断するのは危険だ。

WP-CLIで起きる制約

個人開発のWordPressでは、WP-CLIを使った初期構築やデプロイを自動化することが多い。Docker環境でWordPressを立ち上げ、コマンドでテーマを有効化し、初期データを投入する。こうした流れは、SQLiteとも相性がよさそうに見える。

しかし、WP-CLIのすべてのコマンドがSQLiteで同じように動くわけではない。

一部のコマンドはwpdbを経由せず、MySQLへ直接接続する仕様がある。インポートやエクスポートなどのコマンドでは、SQLite環境で正常に動作しない場合がある。

これは運用の途中で発見すると厄介だ。通常の管理画面では問題なく使えていたのに、デプロイ用のスクリプトだけが失敗する。バックアップからの復元手順だけが動かない。開発環境では手動操作で済ませていた処理が、本番では自動化されている。

採用前に、サイト固有の運用コマンドを書き出しておくとよい。

1. 初期インストールを自動化できるか確認する

WordPress本体の導入、管理者作成、テーマ有効化までを実行する。

2. 投稿データを投入できるか確認する

インポート処理がSQLite環境で動くか、代替手段が必要かを見る。

3. バックアップと復元を試す

データベースファイルのコピーだけで復元できるのか、追加処理が必要なのかを確認する。

4. 本番デプロイの手順を通す

テーマ更新、プラグイン更新、設定変更を含め、実際の運用に近い形で試す。

5. 障害時の手動復旧も確認する

自動化が壊れたときに、管理者がどのファイルとコマンドを扱えばよいか整理する。

技術的に動くことと、運用手順として再現できることは違う。プロダクトでは後者が重要だ。

個人開発におけるSQLite採用の適正ライン

SQLiteを採用しやすいのは、サイトの規模よりも、処理の性質がはっきりしているケースだ。

たとえば個人ブログ、ポートフォリオ、更新頻度の低い企業サイト、小規模なオウンドメディア、検証用のWordPressサイト。公開ページの閲覧が中心で、管理者が少人数、ユーザー投稿がなく、データベースの書き込みが限定されているなら、SQLiteのメリットを生かしやすい。

逆に、次のようなサイトでは慎重になるべきだ。

• WooCommerceを使うオンラインショップ
• 会員登録とログインが中心のサービス
• ユーザーが記事やコメントを頻繁に投稿するサイト
• 複数の編集者が同時に管理画面を使うメディア
• 予約、決済、在庫など状態更新が多いサービス
• アクセス解析やログ保存を大量に行う構成
• 複数の外部サービスとリアルタイムに同期するサイト
• WP-CLIを使ったインポート、エクスポートを頻繁に行う運用

ECサイトや大規模コミュニティサイトでは、同時書き込みの制限が直接的なボトルネックになりやすい。プラグイン互換性の検証範囲も広く、障害時の影響も大きい。

ここで「小規模なら絶対に安全」とは考えないことだ。小規模でも、ログインユーザーが多い、フォーム送信が集中する、バックグラウンド処理が頻繁に走る、といった構成なら書き込み密度は上がる。

判断の軸は、次のように整理できる。

実際に検証するなら、表示ではなく運用を再現する

SQLiteの評価でありがちな失敗は、トップページを開いて問題がなければ合格にしてしまうことだ。

最低限、実際のサイトで発生する操作を再現したい。WordPress本体の表示だけでなく、テーマ、プラグイン、管理者操作、定期処理を含めて確認する。

検証の順序は、次のように組むと進めやすい。

まず構成を小さく固定する

最初から本番と同じ巨大な環境を移行しようとすると、どのプラグインが原因なのか分からなくなる。

WordPress本体、使用テーマ、必須プラグインだけを入れた構成を作る。そこで記事の作成、編集、公開、削除、メディアのアップロードを確認する。問題がなければ、機能を一つずつ追加する。

これは地味だが、原因切り分けの精度を上げる。技術検証では、最初からすべてを入れてしまうと失敗したときに学びが少ない。

次に、書き込みが発生する操作を洗い出す

公開ページの表示だけでは、SQLiteの弱点が見えない。

次の操作を個別に実行する。

• 記事の新規作成
• 下書き保存
• 既存記事の更新
• カテゴリーやタグの変更
• メディアのアップロード
• コメントの投稿
• フォームの送信
• ユーザー登録
• パスワード変更
• プラグイン設定の保存
• 定期タスクの実行

そして、複数の操作が同じ時間帯に重なったときの挙動を見る。エラーが出るか、処理が遅延するか、再試行で回復するか。ここを見ずに本番へ進めると、ユーザーが最初の負荷試験を担当することになる。

最後に、復旧を試す

バックアップは、作成できることより戻せることが重要だ。

SQLiteのデータベースファイル、WordPressのアップロードファイル、テーマ、プラグインを保存し、別の環境で復元する。復元後に管理画面へログインできるか、記事が開けるか、画像が表示されるか、フォームが動くかを確認する。

復旧に失敗したとき、原因がファイル不足なのか、設定の不一致なのか、プラグインの初期化処理なのかを把握できる状態にしておく。バックアップを取っているという安心感だけでは、障害対応は進まない。

「安いから使う」ではなく「複雑さを減らすために使う」

SQLiteを検討する理由として、サーバー費用の削減は確かにある。データベースサーバーを別途用意しなくてよい構成なら、インフラの部品を減らせる。

ただし、費用だけで決めると、後から互換性検証や独自の復旧手順に時間を使うことになる。金額として見えない保守コストが増える可能性もある。

個人開発者にとっては、毎月のサーバー料金より、自分が何時間を保守に使うかのほうが重要な場合も多い。

SQLiteの導入によって、次の作業が減るなら価値がある。

• データベースサーバーの構築
• 接続情報の管理
• 開発環境の複製
• 小規模サイトのバックアップ
• 検証サイトの移動
• 低トラフィック環境の運用

一方で、次の作業が増えるなら慎重に比較したい。

• プラグインごとの互換性確認
• WP-CLIの代替手段の準備
• 同時書き込みの監視
• データベースファイルの保護
• MySQLからSQLiteへの移行手順
• 障害時の復旧テスト
• 将来のデータベース変更に備えた設計

採用の本質は、作業の総量を減らせるかどうかだ。最初の構築が簡単でも、運用中の不確実性が増えるなら、プロダクト全体では複雑になっている。

SQLiteを選ぶ判断は、サーバーを一つ減らせるかではなく、運用中の判断を一つ減らせるかで決めたい。

私ならどのように採用するか

個人開発のWordPressサイトであれば、いきなり既存の本番環境をSQLiteへ移行することはしない。まず新規サイトで採用し、構成を限定して検証する。

理由はシンプルだ。既存サイトには、すでに蓄積されたプラグイン、データ、運用手順がある。そこへデータベースエンジンの変更を加えると、失敗した原因が複雑になる。

新規サイトなら、SQLiteを前提に設計できる。プラグインを選ぶ段階で、独自SQLの有無や書き込み頻度を確認できる。バックアップやデプロイの方法も、最初からSQLite向けに組み立てられる。

私が置く採用条件は、次のようなものになる。

• サイトの主目的が記事や固定ページの公開である
• ユーザーによる書き込みが少ない
• 管理者が同時に編集しない
• 使用プラグインを限定できる
• PHPのPDO SQLite拡張機能とSQLite 3.37.0以降を利用できる
• WP-CLIに依存しない、または代替手順を用意できる
• データベースファイルへの直接アクセスを防げる
• 別環境への復元を事前に確認できる

逆に、事業の中心に会員情報や注文情報があるなら、最初からMySQLやMariaDBを選ぶ。後で移行できる可能性はあっても、移行コストは無料ではない。プロダクトの成長に合わせてデータベースを変える前提で始めるより、最初から書き込み負荷と互換性に強い構成を選んだほうが、ユーザーの痛みを減らせる。

将来の変更を前提に境界を作る

SQLiteを使う場合でも、アプリケーションの設計をSQLite専用に寄せすぎないことが大切だ。

WordPressの標準APIやwpdbを使い、データベース固有のSQLをテーマやプラグインに直接埋め込まない。独自データを保存する場合も、将来MySQLやMariaDBへ戻す可能性を考え、移行しやすい形式を選ぶ。

これはSQLiteのためだけの対策ではない。データベースを変更できる設計は、サービスの寿命を延ばす。

また、ログやアクセス解析の保存先をWordPressのデータベースに集中させない判断も有効だ。読み込み中心のCMSに、不要な書き込み処理を追加すれば、SQLiteの適性を自分で下げることになる。

機能を追加するたびに、「この処理はデータベースへ何を書き込むのか」「その頻度はどの程度か」「失敗した場合にユーザーへ何が起きるか」を見る。技術的な対応可否ではなく、プロダクトの体験で評価する。

結論：小規模サイトなら現実的。ただし、性能より運用設計が先

WordPressのSQLite本番運用は、個人ブログや小規模サイト、更新頻度の低いCMSであれば十分に現実的な選択肢だ。データベースサーバーを省略でき、ファイルベースで管理できる。バックアップや環境移行の考え方もシンプルになる。

一方で、同時書き込みは一つに制限される。会員機能、コメント、フォーム、予約、決済、ログ記録など、書き込みが集中する構成では待機時間が発生しやすい。プラグイン互換性も一括では保証できず、WP-CLIの一部コマンドが正常に動作しない場合もある。

だから、SQLiteの評価は表示速度だけで決めない。

読み込み中心か。書き込みが集中しないか。使用するプラグインが対応できるか。バックアップから復旧できるか。運用を担当する自分が、障害時の手順を理解できるか。

この問いに答えられるサイトなら、SQLiteは個人開発の選択肢になる。逆に、将来のユーザー操作やデータ更新が見えないまま採用するなら、MySQLやMariaDBのほうが安全だ。

SQLite Database Integrationの動向を追う価値はある。公式チームによる検討が続き、WordPressでの利用シーンが広がる可能性もある。ただし、今すぐすべてのサイトを置き換える必要はない。

まずは小さなサイトで仮説を立てる。必要なプラグインだけを入れる。書き込みが重なる操作を試す。復旧まで確認する。そこで得たユーザー反応と運用データをもとに、次のサイトへ広げる。

個人開発では、最初から正解を選ぶことより、失敗しても戻れる構成を作ることのほうが強い。次に試したいことは、SQLiteを使った小規模なWordPress環境で、テーマ、カスタムブロック、最低限のフォームだけを組み合わせ、どこまで保守作業を減らせるかを測ることだ。性能の数字だけではなく、運用の摩擦そのものを検証していきたい。

Related reading: WordPress・CMS設計をわかりやすく解説.