PostgreSQL 19 release and upgrade guide

As of 2026-08-02, the newest public PostgreSQL 19 test build is Beta 2, not a production release. The PostgreSQL roadmap plans version 19 for September 2026, while the Beta 2 announcement gives a more conservative September/October 2026 window. The final date, feature details, and compatibility requirements can still change.

PostgreSQL 19 news and release date

Beta 2 still permits small changes to behavior, APIs, and feature details. Track the PostgreSQL 19 release notes and project news rather than treating a third-party feature list as a launch contract.

PostgreSQL 19 Linux package availability

These snapshots track repository adoption; they are not the authority for PostgreSQL 19 release status. A beta tarball, development build, or container does not prove that a distribution repository provides a production-ready postgresql-19 package. After GA, wait for a complete matrix across the target OS, architecture, extensions, and backup tooling.

What is new in PostgreSQL 19

These are the areas most worth testing as of this review date, not a substitute for the final release notes.

SQL, graph queries, and temporal data

• SQL/PGQ property graph queries define and query property graphs over relational data. Test whether drivers, SQL parsers, ORMs, and AI SQL generators recognize the syntax.
• FOR PORTION OF lets UPDATE and DELETE operate on temporal ranges; Beta 2 still contained several fixes in this area.
• GROUP BY ALL groups all non-aggregate, non-window target-list items.
• Window function IGNORE NULLS / RESPECT NULLS support applies to lead(), lag(), first_value(), last_value(), and nth_value().
• INSERT ... ON CONFLICT DO SELECT ... RETURNING can return the conflicting row and optionally lock it.

Operations, performance, and observability

• REPACK and REPACK CONCURRENTLY unify table-rewrite behavior associated with VACUUM FULL / CLUSTER and add a path with less access-exclusive locking; the old commands remain for compatibility.
• Partition split and merge through ALTER TABLE ... SPLIT/MERGE PARTITIONS.
• Parallel autovacuum workers and new views including pg_stat_autovacuum_scores, pg_stat_lock, and pg_stat_recovery.
• Improvements to asynchronous-I/O read-ahead, SIMD COPY FROM, radix sort, and foreign-key checks.
• An IO option for EXPLAIN ANALYZE, plus full-page-write bytes in EXPLAIN (ANALYZE, WAL).
• LZ4 replaces pglz as the default TOAST compression method for newly compressed data.

PostgreSQL 18 to 19 upgrade considerations

PostgreSQL 18 → 19 is a major upgrade. A version-18 data directory cannot simply be started by version 19. Use pg_upgrade, logical dump/restore, or logical replication, and address these compatibility changes first.

1. Authentication and security

• RADIUS support is removed. Environments that still depend on it need an alternate authentication design before upgrading.
• PostgreSQL 18 deprecated MD5 passwords; version 19 warns after successful MD5 authentication. Move toward SCRAM instead of merely suppressing the warning.
• A password-expiration warning is added with a default seven-day threshold. Ensure monitoring does not misclassify an expected warning as an outage.

2. SQL and object compatibility

• The server now forces standard_conforming_strings to on. If an old environment used off, create logical dumps with PostgreSQL 19 pg_dump / pg_dumpall, or first correct the setting and application escaping behavior.
• Database, role, and tablespace names cannot contain CR/LF; pg_upgrade rejects affected clusters.
• btree_gist indexes over inet / cidr block pg_upgrade because the old operator classes can miss rows. Let pg_upgrade --check identify the actual blockers and follow the release notes.
• The MULE_INTERNAL encoding is removed, so affected databases require dump/restore to another encoding.

3. Defaults, performance, and monitoring

• JIT is disabled by default. Analytical workloads must not assume unchanged plans or runtime; benchmark with jit=off and jit=on.
• max_locks_per_transaction changes from 64 to 128 and lock-memory accounting changes. Recalculate capacity instead of copying the old number blindly.
• pg_stat_subscription_stats.sync_error_count becomes sync_table_error_count; wait-event type BUFFERPIN becomes BUFFER. Update dashboards, alerts, and collectors.
• The TOAST default affects newly written/compressed values; it does not automatically rewrite all old TOAST data to LZ4.

4. Extensions, drivers, and platforms

pg_upgrade checks many core binary properties, but cannot prove third-party modules are binary-compatible with PostgreSQL 19. Record explicit support for PostGIS, pgvector, TimescaleDB, custom C extensions, audit modules, backup agents, pools, ORMs, and drivers.

PostgreSQL 18 to 19 upgrade checklist

Phase A: work you can do now

1. Preserve a PostgreSQL 18 production backup and prove it can be restored.
2. Inventory extensions, collations, slots, tablespaces, custom full-text files, authentication, and external modules.
3. Create a disposable PostgreSQL 19 Beta 2 environment and run migrations, application tests, restore, CDC, and critical-query benchmarks.
4. Compare EXPLAIN (ANALYZE, BUFFERS, WAL) and evaluate the JIT-default and I/O changes separately.
5. Prevent CI or AI agents from sending version-19-only syntax to PostgreSQL 18.

Make PostgreSQL 18.4 the release-blocking production gate and PostgreSQL 19 Beta 2 a forward-compatibility lane. The latter may initially allow failures, but every failure should be classified and cleared before GA adoption. See the complete safe migration and zero-downtime schema workflow.

Phase B: before the production cutover

Run check-only mode using the version 19 pg_upgrade binary. Replace every path with the real target layout:

/opt/postgresql/19/bin/pg_upgrade \
  --old-bindir=/opt/postgresql/18/bin \
  --new-bindir=/opt/postgresql/19/bin \
  --old-datadir=/data/postgresql/18 \
  --new-datadir=/data/postgresql/19 \
  --check

--check does not migrate data, but the rehearsal should use the same binaries, extensions, initdb options, and transfer mode as the cutover. Do not copy the example paths into production unchanged.

Then:

• pin a PostgreSQL 19 GA minor, OS package or container digest, and extension versions;
• choose pg_upgrade copy/clone/link/swap, dump/restore, or logical replication based on the measured workload;
• record downtime, extra disk, statistics rebuild time, and routing/pool convergence time;
• define rollback criteria, owner, and the last safe rollback point;
• verify standbys, slots, sequences, large objects, privileges, RLS, schedulers, and backups.

Phase C: after cutover

1. Run the post-upgrade or rebuild scripts produced by pg_upgrade; do not access tables it flags until those scripts complete.
2. Regenerate the missing optimizer statistics, then compare high-traffic plans and latency.
3. Inspect errors, authentication warnings, replication lag, WAL, autovacuum, locks, and backup jobs.
4. Restore a fresh backup taken from PostgreSQL 19.
5. Remove the PostgreSQL 18 cluster only after acceptance and the rollback window close.

See PostgreSQL 19 pg_upgrade for the complete procedure and Replication, failover, and upgrades for cutover design.

PostgreSQL 19 FAQ

Has PostgreSQL 19 been released?

No. As of 2026-08-02, Beta 2 is the newest release. The roadmap targets September 2026 and the Beta announcement gives a September/October window. Treat official project news as authoritative.

Can PostgreSQL 18 upgrade directly to PostgreSQL 19?

Yes, using a major-upgrade method; there is no requirement to pass through another major. Common choices are pg_upgrade, dump/restore, or logical replication. Use Beta only for rehearsals and wait for GA plus dependency support for production.

How much downtime does an 18-to-19 upgrade need?

There is no universal number. Data size, relation count, transfer mode, extensions and reindexing, statistics, routing, and validation all contribute. Rehearse against a restored copy of representative production data and measure it.

When will managed PostgreSQL services support version 19?

Provider, region, and SKU timelines differ. Do not infer availability from community GA. Track each provider's version matrix and verify extensions, PITR, replicas, and rollback limits. See Cloud PostgreSQL service map.

Should I upgrade from PostgreSQL 18 now?

Build the test matrix now, but do not make a Beta the production default. After GA, wait for explicit support from the extensions, drivers, tools, and managed platform your system actually uses, then schedule around measured benefit and risk.

Fact status and review

Snapshot: PostgreSQL 19 Beta 2, reviewed 2026-08-02. When the project reaches RC or GA, or the release notes add important incompatibilities, update the status, news timeline, upgrade blockers, and updatedAt together.