PostgreSQL 19 Is Out: REPACK, Query Hints, and More

PostgreSQL 19 reached general availability this month after 18 months of development. If you’re expecting a marquee feature reveal, you’ll be slightly disappointed. What you’ll get instead is more useful: the operational pain points that production teams have complained about for years are fixed. Online table rebuilds without exclusive locks. Parallel autovacuum that scales under write pressure. Official query hints, finally. Sequence replication that doesn’t silently break on failover. This is the release that rewards engineers who actually run Postgres in production, not just the ones who talk about it.

REPACK CONCURRENTLY: Rebuild Tables Online, Skip the Maintenance Window

The most operationally impactful change in PostgreSQL 19 is REPACK CONCURRENTLY. Until now, your options for reclaiming table bloat were VACUUM FULL and CLUSTER — both of which hold an ACCESS EXCLUSIVE lock for their entire run. That means zero reads, zero writes, until the operation finishes. For large tables, that meant scheduled maintenance windows and service interruptions.

REPACK CONCURRENTLY changes that. It rebuilds the table into a fresh copy while the original stays fully available under a SHARE UPDATE EXCLUSIVE lock (the same lock VACUUM uses), then swaps the new version in with a brief exclusive lock at the end. Tables stay readable and writable throughout most of the operation. This is essentially what the pg_squeeze extension has done for years — PostgreSQL 19 brings it into core.

-- Reclaim bloat online (no maintenance window required)
REPACK TABLE orders CONCURRENTLY;

-- Reorder by index, online (replaces CLUSTER + downtime)
REPACK TABLE events USING INDEX events_created_idx CONCURRENTLY;

If you’re still scheduling weekend VACUUM FULL jobs, you now have a better option. The official PostgreSQL 19 release notes have the full details on the locking semantics.

pg_plan_advice: PostgreSQL Finally Has Official Query Hints

Oracle has had query hints since 1988. MySQL added them. PostgreSQL held out for decades on philosophical grounds — the planner should figure it out. The community capitulated in 19, but in a distinctly Postgres way.

pg_plan_advice does not embed hints inside SQL. It lives in a GUC setting, generated via EXPLAIN (PLAN_ADVICE) from actual execution plans rather than hand-written guesses. More importantly, it has a feedback mechanism: it tells you whether each hint was honored, partially matched, or silently ignored — with reasons. Oracle hints fail quietly. pg_plan_advice doesn’t.

-- Generate plan advice for a slow query
EXPLAIN (PLAN_ADVICE, FORMAT TEXT)
SELECT o.*, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at > NOW() - INTERVAL '7 days';

-- Apply the generated advice via GUC
SET pg_plan_advice.advice = '{\join_method\:{\orders-customers\:\hash\}}';

The companion module pg_stash_advice stores and automatically re-applies saved advice without setting it on every connection. Aggregation strategy hints are not yet supported, but the foundation is there. See the pg_plan_advice documentation for the full GUC reference.

Logical Replication Sequences: The Silent Data Integrity Fix

This one has been quietly breaking production systems. Logical replication in PostgreSQL 18 and earlier does not replicate sequences. If you promoted a logical replication subscriber to primary during failover, its sequences would start from stale positions — potentially colliding with existing primary key values. The errors don’t always surface immediately, which makes the bug particularly nasty.

PostgreSQL 19 fixes this by replicating sequence nextval() positions alongside table data. Subscribers now sync the publisher’s sequence state, so failover no longer corrupts primary key continuity. The release also lets you enable logical replication without a server restart when wal_level is already set to replica.

Parallel Autovacuum

On write-heavy workloads, autovacuum’s single-process approach to index cleanup creates a lag that accumulates into bloat. PostgreSQL 19 lets autovacuum spawn parallel workers to process a table’s indexes simultaneously, with a new priority-scoring system that focuses attention on tables that need vacuuming most. This won’t eliminate autovacuum tuning, but it raises the throughput ceiling significantly for tables with many indexes.

SQL/PGQ: Graph Queries on Your Existing Tables

PostgreSQL 19 implements the SQL:2023 Part 16 property graph query standard (SQL/PGQ). You define vertex and edge relationships over existing relational tables, then query them with GRAPH_TABLE syntax. No new storage engine, no migration, no separate database.

CREATE PROPERTY GRAPH social_graph
  VERTEX TABLES (users)
  EDGE TABLES (
    follows SOURCE KEY (follower_id) REFERENCES users(id)
             DESTINATION KEY (followee_id) REFERENCES users(id)
  );

SELECT * FROM GRAPH_TABLE(social_graph
  MATCH (a IS users WHERE a.id = 42)-[e IS follows]->(b IS users)
  COLUMNS (b.id, b.username)
);

The initial implementation covers fixed-depth pattern matching. Variable-length path traversal is on the roadmap for a future release. For moderate graph use cases in existing schemas, this is worth testing before reaching for a dedicated graph database. Neon has a solid SQL/PGQ walkthrough if you want to go deeper.

Also: Foreign Keys Are ~2x Faster on Inserts

An optimized constraint validation algorithm roughly doubles insert throughput under foreign key load. If you bulk-load into normalized schemas — order lines referencing orders, events referencing entities — this lands without any schema changes required.

Three Things to Check Before Upgrading

• MD5 passwords: PostgreSQL 19 warns every time a role authenticates with an MD5-hashed password. It still works, but your logs will fill up. Migrate to scram-sha-256 first. Check with: SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';
• MULE_INTERNAL encoding: pg_upgrade refuses to migrate clusters using this encoding. Verify with: SELECT datname, pg_encoding_to_char(encoding) FROM pg_database;
• BUFFERPIN renamed to BUFFER: The wait event class was renamed. Update any monitoring dashboards or alert queries filtering on wait_event_class = 'BUFFERPIN'.

PostgreSQL 14 EOL Is November 12, 2026

If your team is on PostgreSQL 14, you have until November 12, 2026 before it reaches end of life and stops receiving security patches. That is roughly ten weeks from today. Managed cloud providers will silently enroll you in paid extended support after that date if you don’t act. The upgrade path to PostgreSQL 19 is standard pg_upgrade — run the three checks above first.

PostgreSQL 19 isn’t the most exciting major release on paper. It is, however, the one that makes the most difference in production. The fixes are unglamorous by design. That’s the point.