PostgreSQL 19 RC1: REPACK, Breaking Changes, 34 Days

PostgreSQL 19 RC1 landed on October 15. GA is November 19 — 34 days from now. If your team is still on PostgreSQL 14, which hits end-of-life on November 12, the timeline gets tighter: you need to test your upgrade against RC1 today, not when the final release drops. Here is what is new, what will block your upgrade, and how to start testing right now.

REPACK CONCURRENTLY: pg_repack Is Now a Native Command

The headline addition is native table repacking. For years, eliminating table bloat required the third-party pg_repack extension. PostgreSQL 19 folds that capability directly into the engine with two forms: REPACK tablename; (takes an ACCESS EXCLUSIVE lock for the duration) and REPACK tablename CONCURRENTLY; (the version you actually want in production).

The concurrent variant builds a new copy of the table while reads and writes continue against the original. It uses logical decoding to track every change that lands during the copy phase. At the end, it requests a brief ACCESS EXCLUSIVE lock to swap the files. Testing with a 355 MB bloated table produced a 178 MB result, with an INSERT committing mid-rebuild without waiting. If you are currently running pg_repack via cron during maintenance windows, you can drop that workflow after upgrading.

The gotchas are real. REPACK CONCURRENTLY requires roughly 2x the table size in disk space — a 28 GB table needs about 47 GB of peak headroom, including WAL. The temporary replication slot it opens blocks global VACUUM across your entire cluster while it runs. There is also a hard ceiling: if more than roughly 105 million rows change during the operation, it fails at commit. And in RC1, read-only transactions that take a snapshot before the swap completes may briefly see zero rows — documented as not MVCC-safe, fix targeted for PostgreSQL 20.

-- Check current table size
SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_stat_user_tables
WHERE relname = your_table;

-- Run the online repack
REPACK your_table CONCURRENTLY;

Three Breaking Changes That Will Block Your Upgrade

These three issues will stop your upgrade cold or cause production regressions if you do not address them before running pg_upgrade. Run these checks on your current cluster before touching anything else.

1. btree_gist inet/cidr Indexes — pg_upgrade Refuses

pg_upgrade will not proceed on clusters that have btree_gist indexes on inet or cidr columns. The gist_inet_ops and gist_cidr_ops opclasses are broken — they can silently exclude rows that should be returned. Run this first:

SELECT indexname, tablename, indexdef
FROM pg_indexes
WHERE indexdef LIKE %gist_inet_ops%
   OR indexdef LIKE %gist_cidr_ops%;

Drop any results, then recreate them as standard btree indexes after upgrading. If this query returns nothing, you are clear.

2. JIT Is Now Off by Default

Just-in-time compilation has been on by default since PostgreSQL 12. In 19, it flips to off. The reason: the cost model used to decide when to JIT-compile was deemed unreliable, adding latency to short OLTP queries near cost thresholds without meaningful benefit. This is not a regression — it fixes a years-long problem that was silently hurting OLTP performance.

If you run analytical workloads with large sequential scans or complex aggregations, benchmark your critical queries before upgrading:

SET jit = off;  -- New default in PG19
EXPLAIN ANALYZE SELECT ...;  -- Run your heaviest query

SET jit = on;   -- Previous default through PG18
EXPLAIN ANALYZE SELECT ...;  -- Compare results

If analytical queries benefit from JIT, add jit = on to postgresql.conf on those instances. OLTP instances can leave it off and pick up a small latency improvement.

3. standard_conforming_strings Is Now Forced On

This setting has defaulted to on since PostgreSQL 9.1 but could still be disabled. In 19, it is forced on permanently. Applications that use backslash escapes in string literals will break. Audit your codebase for non-standard escape sequences before upgrading — this mainly affects legacy codebases, but it is worth the ten-minute check.

The Other Changes Worth Knowing

Parallel autovacuum arrives with a new autovacuum_max_parallel_workers setting, letting multiple workers handle a large table simultaneously. If you have ever watched a single autovacuum worker crawl through a multi-billion-row table for hours, this is the fix.

Logical replication gains sequence replication — eliminating the primary key collisions that could occur during failover — and a new WAIT command for read-your-writes consistency on standbys. Both address gaps that forced workarounds in production replication setups.

PostgreSQL 19 also ships pg_plan_advice, the database’s first official query hints system. The community resisted hints on principle for years, but real-world production pressure won. You can now pin a query plan by ID and have it applied automatically — meaningful for teams where the planner occasionally picks bad plans on complex OLTP queries.

One removal to flag: SQL/PGQ graph queries, announced in Beta 1 and Beta 2, did not survive to RC1. If you were testing property graph query syntax in the beta builds, that code will not work on 19. It is targeted for PostgreSQL 20.

How to Test RC1 Right Now

AWS has PostgreSQL 19 RC1 available in the RDS Database Preview Environment (US East, Ohio). Instances auto-delete after 60 days at standard RDS pricing — the lowest-friction path to testing a production-like environment. For a faster local start:

docker run --name pg19rc1 \
  -e POSTGRES_PASSWORD=secret \
  -p 5432:5432 \
  -d postgres:19rc1

Run the btree_gist detection query on a dump of your production schema, benchmark your top queries with JIT on and off, and scan application code for backslash escapes. Those three checks cover the most common upgrade blockers for most teams. For a full list of breaking changes, the Neon PostgreSQL 19 breaking changes reference is the most comprehensive rundown available.

The Dates

• October 15: RC1 available — test upgrades now
• November 12: PostgreSQL 14 reaches end-of-life; RC2 released
• November 19: PostgreSQL 19 GA

If you are on PostgreSQL 14, you have 27 days before your database goes unsupported. The RC1 announcement has the full release notes. Start the upgrade test cycle this week.