WordPress on PostgreSQL: the honest answer

Searching for "migrate WordPress to PostgreSQL" usually means one of two very different things. One of them is a trap; the other is a perfectly good idea. This page is blunt about which is which, because most guides aren't.

The hard fact: WordPress core requires MySQL

WordPress's official requirements list MySQL 5.7+ or MariaDB 10.4+ — and nothing else. The core, wp-admin, and the entire plugin and theme ecosystem are written against MySQL. Thousands of plugins issue raw MySQL SQL through $wpdb (functions, backtick quoting, ON DUPLICATE KEY UPDATE, MySQL-specific date math). PostgreSQL is not a drop-in replacement for any of that.

There has historically been one bridge: PG4WP (PostgreSQL for WordPress), a db.php drop-in that rewrites queries on the fly. It can boot a vanilla install, but it is community-maintained, lags new WordPress releases, and only translates the queries it knows about. Any plugin that reaches for a MySQL-only feature breaks — often silently, on a specific admin screen, months later.

When NOT to do it

• A normal production site. If your goal is "run my live WordPress on PostgreSQL," don't. You inherit a compatibility surface the size of the entire plugin directory for no real benefit. Keep it on MySQL or MariaDB.
• To "make it faster." WordPress performance problems are almost always queries, caching and hosting — not the engine. Object caching (Redis), a CDN and a query monitor will move the needle; swapping databases will not.
• Because your stack is otherwise PostgreSQL. Running WordPress against its own managed MySQL/MariaDB instance alongside a PostgreSQL app is the normal, supported architecture. One extra database is cheaper than a permanent compatibility tax.

The one case where it pays off

The legitimate reason to convert a WordPress database to PostgreSQL is to get the data out, not to keep WordPress running on it. Examples:

• You want wp_posts, wp_postmeta and wp_users in your PostgreSQL warehouse for BI, reporting or analytics alongside the rest of your business data.
• You are decommissioning a WordPress site and folding its content into a PostgreSQL-backed app (a headless CMS, a custom Rails/Django service).
• You need a one-time, read-only copy of the content in PostgreSQL to run SQL the WordPress admin can't.

In all of these, WordPress stays on MySQL; you simply produce a PostgreSQL copy of the schema and rows. That is a clean dialect conversion, not a doomed application port.

How to get the data into PostgreSQL

Export the WordPress database with mysqldump:

mysqldump --single-transaction --no-tablespaces \
  -u root -p wordpress > wordpress.sql

Then convert the dialect — the wp_ tables use AUTO_INCREMENT, longtext, tinyint and backtick quoting that all need translating to PostgreSQL equivalents (sequences/identity, text, boolean/smallint, double-quote quoting). Load the result with:

psql -d wp_warehouse -f converted.sql

A note on encoding: WordPress uses utf8mb4, so emoji and multi-byte content are common. PostgreSQL is UTF-8 throughout and handles them natively — no utf8mb4 dance required on the way in.

The bottom line

Don't try to run live WordPress on PostgreSQL — it's unsupported and fragile. Do convert the WordPress database to PostgreSQL when you need the content inside a PostgreSQL system for reporting or as part of a migration off WordPress entirely.

Need the wp_ tables in PostgreSQL? Convert your WordPress dump now →