エックスサーバーのWordPressでSQLiteを使うのはやめておいた方がいいかもしれない

筆者はWordPressのブログを、エックスサーバーとSQLite Database Integrationで運用していました。
どちらも気に入って使っていたのですが、SQLiteプラグインをv3へ更新したところ、エラーが発生。
原因を調べるうちに、思いがけないサーバー側の制約が分かりました。

エックスサーバーもSQLiteも、気に入っていた

エックスサーバーは管理画面が使いやすく、PHPのバージョンも簡単に切り替えられます。
自動バックアップや復元機能が用意され、パフォーマンスやセキュリティ面にも気が配られている。
機能と料金のバランスにも満足していて、WordPressを快適に運用できていました。

一方、SQLiteの魅力はデータベースをファイルとして扱えるシンプルさです。
MySQLやMariaDBのような別のデータベースサーバーを意識せずに済むので、小さなブログにはちょうどいいと考えていました。
データベースをファイル単位で扱えるため、エックスサーバーのファイルバックアップ・復元機能とも相性がよさそうなのも魅力でした。
ただし、稼働中のデータベースを単純にコピーすれば必ず安全に復元できる、という意味ではありません。

以前にはSQLite Database Integrationを紹介する記事まで書いたほどです。
実際の運用でも大きな不満はなく、v3への更新も普段どおりに済むと思っていました。

PHPは新しくできるのに、SQLiteは古かった

SQLite Database Integrationのv3.0では、MySQLのSQLをSQLiteで動かすためのドライバーが刷新されました。
互換性の向上など期待できる変更が多い一方、SQLite本体の最低要件が3.37.0以上に引き上げられています。

旧バージョンのSQLiteに向けて限定的な互換モードも用意されていますが、対象は3.27.0〜3.36系です。
筆者の環境は、その範囲に入りませんでした。

実際に確認できたバージョンは次のとおりです。

この数字を見たときは、正直かなり意外でした。
エックスサーバーは管理画面などの使い勝手が良く、PHPのバージョンも新しいものをすぐに試せ、比較的新しい環境を使えるサービスという印象だったからです。

ただ、PHP本体のバージョンと、PHPのSQLite拡張が利用するライブラリのバージョンは別です。
PHPを新しくしても、SQLiteまで一緒に更新されるとは限りません。

実際、今回の環境ではPHPのバージョンを変えるだけでは解決できませんでした。

これは、2026年11月に筆者が利用していたエックスサーバー環境での確認結果です。
すべてのサーバーや契約プランで同じバージョンだと確認したわけではありません。

データベースのプラグインなら、更新前に止めてほしかった

SQLite Database Integrationは、通常の機能追加プラグインとは事情が違います。
WordPressがデータベースに接続する部分を置き換えるので、互換性がないとサイトそのものが動かなくなるおそれがあります。

v3のリリースノートには新しい要件が書かれていますが、プラグインの更新前に、そのサーバーで使えるSQLiteのバージョンを検査してくれたらよかったのに、と思います。

対応していない環境なら更新を止める。
少なくとも、更新してからWordPressが起動できなくなる事態は避けたいところです。

もちろん、更新前の任意の環境チェックをWordPress標準の更新機構へ組み込むのは簡単ではないかもしれません。
それでもデータベース接続を担うプラグインなら、非対応環境での失敗の仕方まで設計してほしいところ。

公式チームが開発する機能プラグイン（feature plugin）であり、将来のコア統合に向けて検証を進める位置づけだけに、運用中のサイトへの影響にはもう少し気を使ってほしかった、というのが率直な感想です。

SQLiteからMariaDBへ戻すのは、思ったより面倒だった

では、以前使っていたMariaDBへ戻せばいいのでは？

話だけなら簡単です。
実際、SQLite Database Integrationを無効にすると、WordPressは以前のMySQL/MariaDBへ再接続できます。

ただし、公式の説明にもあるとおり、SQLite利用中に更新したデータはMySQL/MariaDBへ同期されません。
以前のデータベースが残っていても、そのまま切り替えると古い状態に戻ってしまいます。

筆者も、どこかで両方のデータベースが同期されているような印象を持っていましたが完全な思い違いでした。

しかも、公式プラグインが提供するのはWordPressをSQLiteで動かす仕組みであって、SQLiteからMariaDBへの完全な往復移行を保証するものではありません。

できれば、ここは泥臭い作業をしたくありませんでした。
バックアップ・復元プラグインでデータを保存し、MariaDBのWordPressへ復元できれば、それで終わるはずだと考えていました。

実際に、UpdraftPlusやAll-in-One WP Migrationをはじめ、バックアップや移行をうたうプラグインをいろいろ試しました。
SQLiteに対応しているとされるものもありましたが、SQLiteでバックアップできることと、そのデータをMariaDBに復元できることは別でした。
このへんはサーバー側のSqliteのバージョン等の相性がありそうな気がします。

筆者が試した範囲では、バックアップ自体はできても、MariaDBへの復元を最後まで完了できるものは見つからず、プラグインだけで移行できる方法は見つかりませんでした。

ここからはSQLを取り出し、MariaDBで読み込める形へ変換する方法に切り替えています。

変換したデータは一度テスト用のMariaDBへ投入して確認し、作業中に更新されたデータとの差分も検証。
最後に54テーブルを移行し、SQLiteプラグインを手動で無効化しました。
WordPressのサイトヘルスでMariaDB 10.11.18への接続を確認し、ようやく完了です。

やりたかったのはデータベースを元に戻すことだけなのに、GitHub Actionsや変換スクリプトまで用意し、検証しながら修正しなおすという、思ったより大がかりな作業になってしまいました。

エックスサーバーでSQLiteを使うべきではないのか

誤解のないように言うと、SQLiteそのものが悪いわけではありません。
ファイルベースのデータベースは小さなアプリに向いていますし、用途次第ではとても便利です。

エックスサーバーも、通常のWordPressをMySQL/MariaDBで運用する分には便利なサービスだと思っています。

今回引っかかったのは、新しいSQLiteを必要とするプラグインと、古いSQLiteライブラリが残るホスティング環境との組み合わせです。

SQLite Database Integrationを使うなら、PHPのバージョンだけでなく、実際にPHPのpdo_sqliteが利用するSQLiteのバージョンを先に確認した方がいいでしょう。
現行のプラグインを動かせるとしても、次の更新で要件が変わる可能性があります。

また、一般的なレンタルサーバーでMySQL/MariaDBが最初から使えるなら、わざわざSQLiteに置き換えるメリットは慎重に考えた方がいいかもしれません。
今回の筆者の環境では、運用を軽くするつもりが、逆に大きな移行作業を抱える結果になりました。

導入しやすさだけでなく、やめやすさも

今回、一番反省したのはSQLiteのバージョンを見落としていたことだけではありません。

大切なデータを預ける仕組みなのに、導入前に出口を確かめていなかった。

SQLiteのファイルをバックアップできることと、必要になったときMariaDBへ問題なく戻せることは別です。
データが手元にあっても、違う形式のデータベースに復元できなければ、移行には変換や検証が必要になります。

SQLiteに限らず、CMS、クラウドサービス、認証基盤などでも同じことが言えそうです。
使い始めるときには便利さが目に付きますが、やめるときや乗り換えるときに何が必要かは、意外と考え漏れているかもしれません。

SQLiteは今でも好きだし積極的に使っていきたいものの、筆者と同様の環境で、運用中のWordPressをあえてSQLite化することは、推奨しにくくなってしまいました。

導入は簡単でも、出口が簡単とは限らない。
それを身をもって知ることになりました。