By PostgreSQL 19 goes GA on November 19. PostgreSQL 14 hits end-of-life on November 12 — one week earlier. If you are on PG14, you have seven days between losing security patches and gaining access to the new major release. If you are on any version, six breaking changes in PG19 can silently crash your upgrade or lock you out of your database before the first connection. None of them are ambiguous. All of them are fixable in advance. You have 21 days.
Why PG19 Shipped Late
LLM-assisted code review got good enough to find bugs faster than PostgreSQL volunteer team could fix them. Committer Peter Eisentraut confirmed about 8 to 10 significant features were reverted from the release branch. SQL Property Graph Queries was the most notable. Tom Lane warned it would ship with unfixable bugs. It got pulled. The delay is not a sign the project is in trouble. It is a sign the quality bar got raised retroactively by tooling that did not exist when those features were written.
The result is a leaner PG19. What survived is solid.
What Is Actually Good
REPACK CONCURRENTLY is the headline feature. It replaces both VACUUM FULL and CLUSTER with a single command that holds an exclusive lock only during the final table swap, not the entire rewrite. Under VACUUM FULL, throughput hits zero while the operation runs. Under REPACK CONCURRENTLY, throughput dips but never reaches zero. That is the difference between a scheduled maintenance window and a command you can run at noon on a Tuesday. One caveat: it builds a full copy of the table on disk, so verify you have headroom before running it on a multi-hundred-GB table.
Parallel autovacuum is the other win. The new autovacuum_max_parallel_workers parameter lets autovacuum assign parallel workers to the index vacuuming phase. Four indexes with three workers means three indexes are processed simultaneously while the leader handles the fourth. Total vacuum time drops to roughly the cost of the largest single index. Heap scanning stays single-threaded, but that is rarely the bottleneck. A new pg_stat_autovacuum_scores view exposes vacuum priority scoring for observability.
The Six Breaking Changes
1. JIT Compilation Is Now Off by Default
JIT has been on by default since PostgreSQL 12. In PG19, it flips to off. The optimizer JIT costing model turned out to be unreliable. It was kicking in for queries that did not need it and adding latency instead of removing it. OLTP workloads will see no change or a slight improvement. OLAP workloads running complex analytical queries may regress silently. Test your heaviest queries with EXPLAIN (ANALYZE, BUFFERS) against both settings before you upgrade. If JIT helps, add jit = on to postgresql.conf explicitly. AWS, GCP, and Azure managed PostgreSQL offerings already disabled JIT by default. PG19 is catching up to their field experience.
2. The pg_upgrade Hard Blocker: btree_gist Opclasses
This one stops the upgrade dead. PostgreSQL 19 marks gist_inet_ops and gist_cidr_ops from the btree_gist extension as non-default because they produce incorrect results. If any index in your cluster uses these opclasses, pg_upgrade halts during its compatibility check and refuses to proceed. Run this detection query now:
SELECT n.nspname, c.relname, i.indexrelid::regclass
FROM pg_index i
JOIN pg_class c ON c.oid = i.indrelid
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_opclass o ON o.oid = ANY(i.indclass)
WHERE o.opcname IN ('gist_inet_ops', 'gist_cidr_ops');If it returns rows, drop those indexes before upgrading and recreate them after. The silver lining: if you had inet or cidr queries relying on them, you were already getting wrong answers.
3. RADIUS Authentication Is Gone
The radius authentication method has been removed entirely from pg_hba.conf. PostgreSQL refuses to start if any pg_hba.conf line uses it. Check before you upgrade with: grep -n radius /etc/postgresql/main/pg_hba.conf. Replace any matches with ldap, scram-sha-256, or another supported method. Very few deployments use RADIUS, but the ones that do will have a bad morning if they do not check.
4. MD5 Passwords: Start the Migration Now
MD5-hashed passwords are deprecated in PG19 and expected to be blocked entirely in PG20. The migration is a strict three-step sequence. The order matters because flipping pg_hba.conf before re-hashing passwords locks out everyone still on MD5.
Step 1: change the default encryption (this does not re-hash existing passwords):
ALTER SYSTEM SET password_encryption = 'scram-sha-256';
SELECT pg_reload_conf();Step 2: find users still on MD5 and have them reset passwords using the psql \password command:
SELECT usename FROM pg_shadow WHERE passwd LIKE 'md5%';Step 3 (only after all passwords are re-hashed): update pg_hba.conf from md5 to scram-sha-256. If you flip this before step 2 is complete, every user still hashed in MD5 gets locked out immediately.
5. standard_conforming_strings Is Locked On
This setting has defaulted to on since PostgreSQL 9.1, but you could still override it server-side. In PG19, it is always on with no override. Applications that build raw SQL strings using backslash escapes will break. Switch to double single-quotes or parameterized queries. If you are not sure whether your application does this, check your database access layer for raw SQL string concatenation.
6. MULE_INTERNAL Encoding Is Dropped
MULE_INTERNAL was an encoding for East Asian scripts from the 1990s. If your cluster has a database still carrying it, that database fails to start after the upgrade. Detection query:
SELECT datname, pg_encoding_to_char(encoding)
FROM pg_database
WHERE pg_encoding_to_char(encoding) = 'MULE_INTERNAL';Convert to UTF-8 before upgrading if you get a result.
Run This Before the Upgrade
Run all the detection queries above. Test JIT on versus off for your heaviest analytical queries. Start the SCRAM migration for any MD5 users. It works without downtime on current PG versions. Then do a dry run against a restored production dump using pg_upgrade --check with your source and target binary and data directories. The check flag runs all compatibility checks without touching data. If it passes against RC1 today, your production upgrade against GA will too. The PG14 EOL deadline is hard. November 12 means 44 CVEs that got fixed this year will not get fixed after that date. Twenty-one days is enough time to do this right. Start the checklist now.
