The September 24 signal: beta 4 and removed features
PostgreSQL 19 beta 4 was released on September 24, 2026 on postgresql.org/about/news/. The standard PostgreSQL release cycle calls for 3 to 4 betas before the October general availability; a fourth beta in September signals that the project has not reached its target stability level on schedule.
The notable news in this beta is not a technical fix — it is the removal list. Analysis published by the Snowflake engineering team counts 53 features originally planned for PostgreSQL 19 that have been deferred to a later release. This kind of mass deferral in beta is rare in the project's history, which has maintained a very consistent annual cadence for twenty years.
Direct consequence: PostgreSQL 19 GA is now expected in late October 2026, several weeks later than the original schedule. For a self-hosted production stack, this shift is not trivial: it compresses the testing window before the year-end freeze and pushes the entire migration calendar back.
What was removed and why it matters
Among the 53 removed features, three groups deserve attention from developers working with modern application stacks.
Removals that affect application developers
- SQL/JSON path improvements — improvements to
jsonpathnavigation in nested JSON documents, widely used in REST APIs storing semi-structured data (user profiles, application logs, dynamic configurations). Their removal means queries that relied on them must continue to use more verbose alternatives. - SQL graph queries (ISO SQL:2016) — support for graph queries per the ISO SQL:2016 standard, which would have allowed modeling complex relationships (category trees, social networks, dependency chains) directly in standard SQL, without extensions. This removal is significant for projects wanting to migrate from NoSQL solutions to PostgreSQL.
- MERGE improvements backported to PG 18 — improvements to the
MERGEclause (added in PostgreSQL 15, enhanced in 16 and 17) that were planned for PG 19 have been deferred. Some have been backported to PostgreSQL 18, which retroactively strengthens the appeal of that version.
Why these removals don't invalidate PG 19
A feature removal in beta is a sign of maturity, not failure. The PostgreSQL project prefers shipping less over shipping unstable — this is what earns its reputation for production reliability. The 53 removed features will be candidates for PostgreSQL 20. What should hold your attention is the timeline: the testing window before GA is now very short.
Concrete impact by self-hosted stack
The practical question is not "is PostgreSQL 19 good?" but "which version does my stack run on, and does PG 19 change anything about my migration plan?" The four most common tools on self-hosted VPS have documented prerequisites that shape the answer.
n8n documents PostgreSQL 14+ as its supported database. In self-hosted production, n8n instances run mostly on PG 14 or PG 15 — a migration to PG 18 is a controlled jump, with no PG 19 features required by the application itself.
Supabase distributes PostgreSQL 15 by default in its self-hosted image. The project follows stable releases with an internal qualification delay of a few weeks. PG 19 will not be supported until several months after GA; targeting PG 18 for a self-hosted Supabase instance is the coherent trajectory.
Nextcloud 35 lists PostgreSQL 15+ in its official documentation. Earlier versions (Nextcloud 30 to 34) already supported PG 14. No PG 19 features are required by Nextcloud today.
Mattermost Team Edition documents PostgreSQL 14+ as a prerequisite. Migrating to PG 18 requires no application changes — the schema is compatible.
PostgreSQL version required by self-hosted application
Scroll the table
| Application | Minimum documented PG version | Default distributed PG version | Compatible with PG 18 | Requires PG 19 |
|---|---|---|---|---|
| n8n | PG 14+ | PG 14 or 15 depending on image | Yes (no application changes required) | No |
| Supabase self-hosted | PG 15+ | PG 15 (official image) | Yes (qualification in progress) | No |
| Nextcloud 35 | PG 15+ | PG 15 recommended | Yes | No |
| Mattermost Team Edition | PG 14+ | PG 14 or 15 | Yes | No |
The recommendation: PostgreSQL 18 is the healthy intermediate target
PostgreSQL 18 reached general availability in April 2026. It has a five-year support lifecycle (until 2031) and has been stable in production for several months. This is the version teams planning PG 19 should target now.
Three concrete reasons favor PG 18 as an intermediate target:
1. MERGE improvements that were meant for PG 19 have been partially backported to PG 18 — you benefit from them without waiting.
2. The PG 17 → PG 18 migration is documented and has no major friction. Compatibility for common extensions (pgvector, PostGIS, TimescaleDB) is ensured.
3. Five years of support from April 2026 — no immediate upgrade pressure, and a comfortable window to qualify PG 19 once it is truly stable in production.
The correct strategy: migrate to PG 18 now, plan PG 19 for 2027 (after the first production feedback).
PG 16/17 → PG 18 migration guide
Major PostgreSQL migration is performed with pg_upgrade, the project's standard tool. It requires a service stop but no full reinstallation — the catalog and data are preserved.
Steps to migrate PG 16 or PG 17 to PG 18
Back up the database before any operation
A major migration is irreversible without a backup. Take a full dump:
pg_dumpall -U postgres > /backup/pg_full_$(date +%Y%m%d).sqlVerify the file is readable and non-empty before continuing. On a VPS, also copy the dump to external storage (S3 bucket, remote server).
Install PostgreSQL 18 alongside the existing version
On Debian/Ubuntu, the PGDG repository allows installing multiple versions side by side:
apt install postgresql-18Both instances coexist (different ports: 5432 for the old one, 5433 for the new one by default).
pg_upgradewill migrate between the two clusters without starting the old instance.Stop the old instance and run pg_upgrade
Cleanly stop the old instance (PG 16 or PG 17):
systemctl stop postgresql@16-main # or depending on your version systemctl stop postgresql@17-mainRun
pg_upgradein check mode (--check) first:pg_upgrade \ -b /usr/lib/postgresql/17/bin \ -B /usr/lib/postgresql/18/bin \ -d /var/lib/postgresql/17/main \ -D /var/lib/postgresql/18/main \ --checkIf the check passes without errors, run again without
--checkto perform the migration.Reconfigure the port and restart
After migration, point your application to the PG 18 cluster. If you keep port 5432, edit
/etc/postgresql/18/main/postgresql.conf:port = 5432Start the PG 18 instance:
systemctl start postgresql@18-mainCheck the active version:
psql -U postgres -c "SELECT version();"Analyze and clean up after migration
After
pg_upgrade, rebuild statistics on all databases (required for the query optimizer):vacuumdb --all --analyze-in-stages -U postgresOnce validated, you can remove the old cluster and its packages:
/usr/lib/postgresql/17/bin/pg_dropcluster 17 main apt remove postgresql-17
Checking your PostgreSQL version in production
Before planning anything, knowing the exact version in production is essential. Commands vary depending on the installation context.
Version diagnostic commands
- Via psql:
psql -U postgres -c "SELECT version();"— displays the full version including the patch number. - Via systemctl:
systemctl status postgresql— shows the name of the active service, which contains the major version number. - Via Docker:
docker exec <container> psql -U postgres -c "SELECT version();"for a containerized instance. - Via pg_lsclusters (Debian/Ubuntu):
pg_lsclusters— lists all installed clusters, their port, status and version. Useful when multiple versions coexist. - Via application logs: n8n, Supabase and Mattermost all log the PostgreSQL version at startup — check the logs if you don't have direct server access.
Planning the PG 19 migration: timeline and precautions
PostgreSQL 19 GA is expected in late October 2026. The realistic timeline for production self-hosted adoption looks like this:
- Late October 2026: PG 19 GA, first PGDG packages available.
- November–December 2026: period to avoid for production migrations — year-end freeze, understaffed teams, high operational risk.
- January–February 2027: first PG 19 maintenance patch (usually 2 to 4 weeks after GA). This is the standard signal to consider staging testing.
- Q1–Q2 2027: qualification on a staging instance with an anonymized production dump, extension validation, performance testing.
- Q2–Q3 2027: production migration for teams that have completed the full validation cycle.
Three precautions never to skip:
1. Test first on an anonymized production dump, not synthetic test data — real volumes and query patterns reveal regressions that fixtures miss.
2. Check the compatibility of each extension before migrating: pgvector, PostGIS, pg_cron, pg_trgm each have their own qualification cycle for each major version.
3. Keep a documented rollback plan: with pg_upgrade, rolling back is possible as long as you haven't deleted the old cluster — document the restore procedure before migrating.
Setting up your VPS for PG 18 with Docker
If your stack already runs on Docker, migrating to PG 18 can be done alongside the production instance, without pg_upgrade. The official postgres:18 image has been available on Docker Hub since the April 2026 GA.
Deploy PG 18 on a VPS with Docker Compose
Create the docker-compose.yml file for PG 18
Create a dedicated directory and configuration file:
mkdir -p /opt/postgres18 && cd /opt/postgres18Content of
docker-compose.yml:cat > docker-compose.yml << 'EOF' services: postgres: image: postgres:18 container_name: postgres18 restart: unless-stopped environment: POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} POSTGRES_USER: ${POSTGRES_USER:-postgres} POSTGRES_DB: ${POSTGRES_DB:-app} volumes: - ./data:/var/lib/postgresql/data ports: - "127.0.0.1:5432:5432" EOFCreate a
.envfile with your values:echo 'POSTGRES_PASSWORD=strong_password_here' > .envImport data from the old instance
Start the new container:
docker compose up -dRestore the dump from your old instance (PG 16 or PG 17):
psql -U postgres -h 127.0.0.1 -p 5432 < /backup/pg_full_$(date +%Y%m%d).sqlVerify that databases and tables are present:
docker exec postgres18 psql -U postgres -lVerify and switch your application
Before switching the application, check the active version in the container:
docker exec postgres18 psql -U postgres -c "SELECT version();"Update the
DATABASE_URLvariable (orDB_HOST/DB_PORT) of your application to point to the new container. Restart the application and check the startup logs — n8n, Nextcloud and Mattermost all log the PostgreSQL connection on initialization.
A VPS with root access gives you the margin managed hosting doesn't
Testing PG 18 alongside your production instance, validating your stack on an anonymized dump, and rolling back without depending on a vendor: that's what root access on a VPS makes possible. Shared hosting or managed PaaS imposes the provider's upgrade schedule — often without advance notice of the target version or the ability to test beforehand.
Conclusion: act now, not after the PG 19 GA
PostgreSQL 19's delay and the removal of 53 features are not alarm signals about project quality — it's the normal publication process for software of this scope. But they change the timeline for teams planning a direct jump to PG 19 before end of 2026.
The action window is now, before the PG 19 GA:
- If you are on PG 15 or PG 16: plan the migration to PG 18. It is the stable version, supported for 5 years, whose features cover all the prerequisites of common self-hosted stacks (n8n, Supabase, Nextcloud, Mattermost).
- If you are on PG 17: you are in a good position. PG 17 remains supported until 2029; migration to PG 18 can wait for a quiet maintenance cycle.
- In all cases: do not plan PG 19 in production before Q2 2027 — extension qualification and first production feedback require several months after GA.
The migration calendar is decided when options are open, not when operational pressure closes the doors.
