Add PostgreSQL as a first-class WordPress test backend

[adamziel]

Big picture

Adds PostgreSQL backend in addition to the SQLite backend.

How to try it locally

PostgreSQL is selected with WP_TEST_DB_BACKEND=postgresql; the aliases postgres and pgsql work too.

# Generate the WordPress checkout, PostgreSQL Docker override, test configs,
# plugin drop-in wiring, and local-env node dependencies.
WP_TEST_DB_BACKEND=postgresql composer run wp-setup

# Start and install the WordPress test site on PostgreSQL.
WP_TEST_DB_BACKEND=postgresql composer run wp-test-start

# Run the WordPress PHPUnit suite against PostgreSQL.
WP_TEST_DB_BACKEND=postgresql composer run wp-test-php

# Or run the WordPress e2e suite against PostgreSQL.
WP_TEST_DB_BACKEND=postgresql composer run wp-test-e2e

That setup writes PostgreSQL-specific generated files under wordpress/, including:

• wordpress/docker-compose.override.yml with DB_ENGINE=postgresql, DATABASE_ENGINE=postgresql, a postgres service, and the inherited MySQL service reset;
• wordpress/wp-config.php and wordpress/wp-tests-config.php with PostgreSQL constants;
• wordpress/src/wp-content/db.php plus the copied sqlite-database-integration plugin target that loads the PostgreSQL wpdb adapter;
• PostgreSQL PHP/CLI Dockerfiles that install pdo_pgsql.

For a clean rebuild, use:

WP_TEST_DB_BACKEND=postgresql composer run wp-test-clean
WP_TEST_DB_BACKEND=postgresql composer run wp-setup

If a previous interrupted setup left .wp-setup.lock behind, remove it only after confirming no wp-setup.sh or composer run wp-setup process is still running.

What changed

• Added a PostgreSQL driver path for the MySQL-on-SQLite package architecture.
• Added PostgreSQL WordPress drop-in wiring, install helpers, local-env generation, and CI runner support.
• Added PostgreSQL package coverage for query translation, DDL, SQL modes, runtime functions, upserts, metadata, connection behavior, and wpdb behavior.
• Added CI coverage so PostgreSQL is a real signal, not a best-effort or continue-on-error job.
• Closed the main parity gaps found while running the WordPress test suite against PostgreSQL, including:
  • zero-date and empty temporal values;
  • DATE_ADD(), DATE_SUB(), TIMESTAMPDIFF(), DATE_FORMAT(), and related temporal functions;
  • ON DUPLICATE KEY UPDATE, VALUES(), LAST_INSERT_ID(id), and ROW_COUNT() behavior;
  • CREATE TABLE, ALTER TABLE, CREATE TABLE LIKE, and metadata preservation;
  • information_schema, SHOW, SQL mode, and session-variable compatibility;
  • common runtime functions used by WordPress and plugin-style SQL.

Validation

The current PR checks are passing, including code style, package PHPUnit, WordPress PHPUnit, WordPress e2e, MySQL proxy tests, lexer benchmark, WASM extension build, and release metadata checks.

Local validation also included focused regression runs for the PostgreSQL failures found during parity work, plus the full package-level PostgreSQL suite:

• packages/mysql-on-sqlite PostgreSQL suite: OK (897 tests, 7181 assertions)
• latest focused PostgreSQL driver regression slice: OK (6 tests, 133 assertions)
• composer check-cs -- --no-cache --report-summary: 19 / 19 (100%)

WordPress PHPUnit: SQLite 24,648 passed; PostgreSQL 24,628 passed
[####################] 100%

Known limitations and review notes

• PostgreSQL support is explicit backend support for this integration layer; SQLite remains the default path.
• The PostgreSQL translator intentionally fails closed for unsupported MySQL syntax instead of guessing. New unsupported patterns should be added with focused parity tests before being broadened.
• Local WordPress PostgreSQL runs depend on generated wordpress/ checkout files, node modules, Docker images, and config artifacts. Stale generated state can produce misleading local results; rerun the setup path before trusting local WordPress runtime output.
• The CI and package tests show the backend is practical for the current WordPress test surface. They are not a guarantee that every production plugin query shape is already covered.
• Performance work here focused on keeping the CI lane usable and preventing obvious regressions. Real workload profiling should be a separate follow-up once the compatibility surface settles.

Reviewer focus

The highest-value review areas are the backend translation boundaries, fail-closed behavior for unsupported MySQL syntax, WordPress config/setup generation, and the CI contract that keeps PostgreSQL failures visible.