PostgreSQL

Not for WordPress, and not on every PHP

A PostgreSQL site must be Laravel or blank PHP, and its PHP must be one of rexenv’s own 8.1–8.5 builds. PHP 7.4 and 8.0 have no working pdo_pgsql, and neither does an upstream patch a PHP update can install. Both limits are refused at create time, below — never discovered at the first migration.

Versions

18.6.0 (default), 17.11.0, 16.15.0, on port 15432.

rex service start postgres
rex db versions --set postgres 17.11.0

Through 0.4.0 the PostgreSQL builds rexenv pinned were compiled for macOS 26 and would not launch below it. The current pins are measured at macOS 15 — every executable and library in all six tarballs. rexenv itself now runs on macOS 13 and 14 (it needed 15 through 0.8.6), which is where the two floors part: macOS 14 gets 16.4.0 only, the last build that loads there, and macOS 13 gets no PostgreSQL — the arm64 builds all need 14. The app says so wherever you could pick it: “Needs macOS 14 or later — this Mac runs macOS 13.6.”

As a site’s database

Pick PostgreSQL in the New Site dialog’s Database field, or:

rex site create api.rex --type laravel --php 8.4 --db postgres

The dialog offers PostgreSQL only where it would work. For WordPress the option is absent. For Laravel or blank PHP on a PHP without the driver, it says why in the place the option would have been — a field that silently has fewer options than it did on another site reads as a bug:

PostgreSQL needs PDO, and the PHP 8.0 build has no working pdo_pgsql — pick a newer PHP above to use it.

Anything that skips the dialog — rex, an agent — gets the refusal itself. For WordPress:

WordPress cannot run on PostgreSQL — core’s database layer speaks MySQL only. Use MySQL or MariaDB for a WordPress site; PostgreSQL is available for Laravel and Blank PHP sites.

For a PHP without the driver:

PHP 8.0.30 cannot reach PostgreSQL — a PostgreSQL site talks to its database through PDO, and that build has no working pdo_pgsql (it advertises the driver and then hangs; measured against PostgreSQL 16, 17 and 18). Use PHP 8.1 or newer for this site, or MySQL/MariaDB on this one.

A refused create leaves nothing behind: the check runs before the docroot, the starter page or the certificate is made.

“Advertises the driver and then hangs” is the whole reason rexenv now builds its own PHP. The static-php.dev builds it used to ship accept a PDO pgsql connection and stall for about a minute until PostgreSQL closes it — and php -m reports the driver as present. See rexenv builds its own PHP.

What a PostgreSQL site is wired with

host      127.0.0.1
port      15432
user      postgres
password  (none)
database  the site's own

A Laravel site’s .env gets every connection key, whether the file had it or not — so a fresh skeleton’s DB_CONNECTION=sqlite is replaced rather than left to win:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=15432
DB_DATABASE=<the site's database>
DB_USERNAME=postgres
DB_PASSWORD=

A blank PHP site with a starter database gets the same seeded starter_items table and db.php as on MySQL, with a pgsql: DSN.

One superuser, no password

The server is initialised with trust authentication and a passwordless postgres superuser, listening on 127.0.0.1 only. That is a local-development posture: a PostgreSQL site’s credentials reach every database on this server, not only its own. MySQL and MariaDB sites get per-site credentials; PostgreSQL sites do not.

The one-click config rewrite on a site’s Database tab changes host, port and user — never the driver. A Laravel project whose .env still names another driver is refused rather than half-rewritten:

this site’s database lives in PostgreSQL, but the config says driver — the one-click change covers the host, port and user, not the driver. Set DB_CONNECTION yourself (the Database tab has the connection lines), then run this again.

What else behaves differently

• Switching an existing PostgreSQL site to PHP 7.4 or 8.0 is not refused. The driver check runs at create time, not on a PHP switch, so the site then stops reaching its database until you switch it back to 8.1 or newer. This is a gap, and it is stated rather than left to be found.

• Start all starts PostgreSQL when any site’s database lives there. Before, a PostgreSQL site could come up with nothing listening on 15432.

• Deleting a site drops its database WITH (FORCE), so an open Adminer tab or a running artisan connection cannot keep a deleted site’s database alive.

• Export is pg_dump --no-owner --no-privileges, written to ~/Downloads like the other engines.

• Adminer deep-links into the site’s database as for MySQL.

• Importing from Valet or Herd does not bring PostgreSQL data. The importer still says so in as many words: “rexenv can’t import PostgreSQL databases yet — MySQL and MariaDB only for now. Everything else about this site imports normally.”

A PHP update can take the driver away

A patch update may install upstream’s build rather than rexenv’s, and upstream’s has no pdo_pgsql. The Settings row warns before the click — a costs PostgreSQL chip, naming the sites that would stop reaching their database — but it does not refuse. See An update can cost PostgreSQL.

Major versions never share a data directory

PostgreSQL major versions have mutually incompatible on-disk formats — a 17 server cannot read an 18 data directory, and pointing it at one is how people lose databases.

rexenv gives each major its own directory. Switching from 18 to 17 starts 17 with 17’s data, leaves 18’s alone, and does not attempt an in-place downgrade. Switch back and your 18 databases are where you left them.

Moving data across a major version is an explicit dump and restore, as it is everywhere else:

rex db export myapp.rex
rex db import myapp.rex dump.sql

Connecting

host      127.0.0.1
port      15432

The site’s page shows its database name and credentials, and rex db browse opens Adminer connected to it.

If it will not start

Check your macOS version first — on 13 there is no PostgreSQL at all, on 14 only 16.4.0, and on 0.4.0 or earlier those pins will not run below 26:

sw_vers -productVersion
rex --version

Past that, rex doctor reports port conflicts and the rest, and rex logs lists the engine’s own log.

One start failure needs no action from you any more: after an unclean shutdown, PostgreSQL’s “lock file already exists — is another postmaster running?”. A start now removes a postmaster.pid whose process id is no longer a PostgreSQL server, and the log names what it removed — Databases has the mechanism.