結論から言うと、WordPress コアは PostgreSQL に対応していません。公式に動作対象としているのは MySQL と MariaDB だけで、PostgreSQL で動かすにはクエリを変換する非公式の仕組みが必要になり、プラグインやテーマとの互換性は保証されません（2026年10月現在）。この記事では、なぜそのまま動かないのか、変換レイヤーを使う場合のリスク、そして「PostgreSQL に寄せたい」という本来の目的を満たす現実的な選択肢を整理します。
なぜ WordPress は PostgreSQL でそのまま動かないのか
WordPress はデータベースの抽象化層を持たず、wpdb クラスが MySQL 方言の SQL をそのまま送る設計です。コアだけでなく、多くのプラグインが $wpdb->query() や $wpdb->get_results() に手書きの SQL を渡しています。PostgreSQL と食い違う代表的な点は次のとおりです。
- 識別子の書き方: MySQL のバッククォート（`
- 件数取得の仕組み: WP_Query はページ送りのために
SQL_CALC_FOUND_ROWSとFOUND_ROWS()を使いますが、PostgreSQL には対応する構文がありません。 - INSERT ... ON DUPLICATE KEY UPDATE: オプションの保存などで使われます。PostgreSQL では
ON CONFLICTという別構文です。 - テーブル作成: プラグインの有効化時に使われる
dbDelta()は MySQL の CREATE TABLE 文を前提に解析します。AUTO_INCREMENT、UNSIGNED、プレフィックス付きインデックスなどはそのままでは通りません。 - ゼロ日付:
0000-00-00 00:00:00を既定値として使う箇所があり、PostgreSQL の日付型では受け付けられません。 - 関数の違い:
FIELD()（post__in 順の並べ替えに使用）、RAND()、DATE_FORMAT()などは名前や挙動が異なります。 - 文字列比較: MySQL の一般的な照合順序は大文字小文字を区別しませんが、PostgreSQL は既定で区別します。ユーザー名やスラッグの検索結果が変わる可能性があります。
- GROUP BY の緩さ: MySQL の設定によっては許される書き方が、PostgreSQL ではエラーになります。
コアの SQL だけなら変換で吸収できても、数十のプラグインがそれぞれ独自の SQL を持つため、移行の難しさはプラグイン構成に比例して大きくなります。
変換レイヤーを使う方法とそのリスク
PG4WP（PostgreSQL for WordPress）
wp-content/db.php というドロップイン（wpdb を差し替える仕組み）を置き、MySQL 方言の SQL を正規表現などで PostgreSQL 向けに書き換えるプロジェクトです。長く更新が止まっていた時期があり、その後コミュニティによるフォークで開発が続けられています。導入する場合は次の点を前提にしてください。
- 対応している WordPress のバージョンと、既知の不具合を GitHub のリポジトリで確認する
- コアの機能は動いても、プラグイン固有の SQL は個別に動作確認が必要
- WordPress 本体やプラグインの更新で新しい SQL が追加されると、変換が追いつかずに壊れることがある
- 不具合が起きてもプラグインの作者やホスティングのサポートを受けにくい
小規模な検証環境で試す価値はありますが、業務サイトの本番環境に使うかどうかは慎重に判断すべきです。
公式の変換レイヤーは SQLite 向け
WordPress のパフォーマンスチームが開発している「SQLite Database Integration」プラグインは、同じく db.php の仕組みで MySQL の SQL を SQLite 向けに変換します。WordPress Playground でも使われている技術ですが、対象は SQLite で PostgreSQL ではありません。データベースサーバーを用意せずに開発・検証環境を作る用途には向いていますが、PostgreSQL 移行の代わりにはなりません。
移行を検討する前に、目的を確認する
「PostgreSQL にしたい」という要望の背景によって、適切な答えは変わります。
- 社内のデータベースを PostgreSQL に統一したい: 運用の標準化が目的なら、WordPress 用だけは MySQL / MariaDB を例外として残す方が、変換レイヤーの保守より負担が小さいことが多いです。
- スケーラビリティや可用性を上げたい: マネージドの MySQL 互換サービス（Amazon RDS for MySQL、Amazon Aurora MySQL 互換、Google Cloud SQL for MySQL など）を使えば、レプリカやバックアップ、フェイルオーバーを WordPress の互換性を崩さずに得られます。機能や構成はサービスごとに異なるため、各社のドキュメントで確認してください。
- PostgreSQL 上の業務データと WordPress のデータを組み合わせて分析したい: WordPress のデータベースはそのままにして、分析側で取り込む方法が現実的です。
現実的な代替手段
WordPress は MySQL のまま、データを PostgreSQL 側から参照する
PostgreSQL の外部データラッパー（mysql_fdw などの拡張）を使うと、PostgreSQL から MySQL のテーブルを外部テーブルとして参照できます。拡張の導入可否はマネージドサービスによって異なるため、利用環境で使えるかを確認してください。リアルタイム性が不要なら、定期的にデータを書き出して PostgreSQL に取り込む方法もあります。
データの一括コピーには pgloader
pgloader は MySQL から PostgreSQL へスキーマとデータを移すツールです。分析用の複製を作る用途には便利ですが、移した先で WordPress が動くようになるわけではありません。あくまで「データを PostgreSQL で扱いたい」場合の手段です。
ヘッドレス構成で役割を分ける
アプリケーション本体は PostgreSQL を使う別のシステムで作り、記事などのコンテンツ管理だけを WordPress（MySQL）に任せて、REST API や WPGraphQL 経由で取得する構成です。WordPress 側の互換性を保ちつつ、データベースの選択をアプリケーション側で自由にできます。
それでも試す場合の進め方
検証目的で変換レイヤーを試すなら、次の手順で影響を確認します。
- 本番のバックアップ（データベースとファイル）を取り、本番とは切り離したステージング環境を用意する
- 使っているプラグインとテーマの一覧を作り、独自テーブルや手書き SQL を持つものを洗い出す
- pgloader などでデータを移し、変換レイヤーを導入する
- 投稿・固定ページの表示、検索、ページ送り、管理画面の一覧、プラグインの有効化・無効化、更新処理を一通り確認する
- エラーログ（
WP_DEBUG_LOG）とデータベースのログを確認し、変換に失敗した SQL を記録する - WordPress やプラグインを更新したときに同じ確認をやり直す運用を続けられるかを判断する
最後の項目が重要です。初回に動いても、更新のたびに検証が必要になる点が、この構成の継続コストになります。
まとめ
- WordPress コアの公式な動作対象は MySQL / MariaDB で、PostgreSQL は非対応
- 非互換の原因は MySQL 方言の SQL（バッククォート、SQL_CALC_FOUND_ROWS、ON DUPLICATE KEY UPDATE、dbDelta、ゼロ日付など）と、プラグインの手書き SQL
- PG4WP のような変換レイヤーは存在するが、互換性と保守のリスクが大きく、本番利用は慎重に
- 目的がスケーラビリティならマネージド MySQL 互換サービス、データ活用なら外部データラッパーや pgloader、システム分離ならヘッドレス構成が現実的