PostgreSQL 19 is at Beta 2, with the final release expected around September or October, so syntax and behavior can still shift. Two things in this cycle are worth the upgrade on their own: SQL/PGQ property graphs, and the new REPACK command.

Property Graphs Behave Like Views

SQL/PGQ comes from SQL:2023 (ISO/IEC 9075-16), and CREATE PROPERTY GRAPH materializes nothing. It is a new relkind that acts like a view: the rewriter turns your graph pattern into a plain relational query against the underlying tables, using the indexes you already have.

Take a small asset inventory: domains, the hostnames they publish, and the addresses those hostnames resolve to.

CREATE TABLE domains (
    domain_id integer PRIMARY KEY,
    name text NOT NULL
);

CREATE TABLE hosts (
    host_id integer PRIMARY KEY,
    hostname text NOT NULL
);

CREATE TABLE addresses (
    address_id integer PRIMARY KEY,
    ip inet NOT NULL
);

CREATE TABLE domain_hosts (
    domain_hosts_id integer PRIMARY KEY,
    domain_id integer REFERENCES domains (domain_id),
    host_id integer REFERENCES hosts (host_id),
    record_type text NOT NULL
);

CREATE TABLE host_addresses (
    host_addresses_id integer PRIMARY KEY,
    host_id integer REFERENCES hosts (host_id),
    address_id integer REFERENCES addresses (address_id)
);

Entity tables become vertices, join tables become edges, and the definition stays short because the keys already describe how everything connects:

CREATE PROPERTY GRAPH infra
    VERTEX TABLES (
        domains   LABEL domain,
        hosts     LABEL host,
        addresses LABEL address
    )
    EDGE TABLES (
        domain_hosts   SOURCE domains DESTINATION hosts     LABEL resolves_to,
        host_addresses SOURCE hosts   DESTINATION addresses LABEL has_address
    );

Without those keys you spell them out with KEY (...), SOURCE KEY (...) REFERENCES ..., and DESTINATION KEY (...) REFERENCES .... Queries go through GRAPH_TABLE, which sits in the FROM clause and acts like a table function:

SELECT domain_name, hostname
FROM GRAPH_TABLE (infra
    MATCH (d IS domain)-[IS resolves_to]->(h IS host)
          -[IS has_address]->(a IS address WHERE a.ip = inet '203.0.113.10')
    COLUMNS (d.name AS domain_name, h.hostname AS hostname)
)
ORDER BY domain_name;

The same question the old way, which is what the rewriter produces anyway:

SELECT d.name, h.hostname
FROM domains d
    JOIN domain_hosts dh ON dh.domain_id = d.domain_id
    JOIN hosts h ON h.host_id = dh.host_id
    JOIN host_addresses ha ON ha.host_id = h.host_id
    JOIN addresses a ON a.address_id = ha.address_id
WHERE a.ip = inet '203.0.113.10'
ORDER BY d.name;

At two hops it is a wash. The graph version stops growing at four, while the join version keeps piling up aliases and ON clauses that all have to stay correct.

The Pattern Language

A vertex is (), an edge is -[]->, and a path alternates between them. Labels match with IS, and | means “or”. Edges are directed, so <-[ ]- goes the other way and -[ ]- matches either. Drop the brackets when the edge needs no filter of its own:

(IS host)-[IS has_address]->(IS address|cidr_block)
(IS address)<-[IS has_address]-(IS host)
(IS domain)->(IS host)->(IS address)

Bind a variable and you can pull its properties in COLUMNS, including columns off the edge table itself:

MATCH (d IS domain)-[r IS resolves_to]->(h IS host)
COLUMNS (d.name AS domain_name, r.record_type AS via, h.hostname AS hostname)

Now the part that decides whether this is useful to you. PostgreSQL 19 implements the core of SQL/PGQ and leaves most optional subfeatures out, and the omissions cluster in one place: variable-depth traversal. The conformance appendix lists quantified paths (G035), quantified edges (G036), bounded and unbounded quantifiers (G060, G061), path variables (G004), and shortest-path search (G017, G018) as unsupported. Label conjunction (G071), negation (G072), and wildcards (G074) are out too, leaving | as your only operator.

So every hop gets written out. You cannot ask for “anything reachable within three hops” or “the shortest path between these two vertices”, which is what most people mean when they say graph query. Transitive closure and reachability still belong to recursive CTEs. Fixed-depth traversal over a known shape is what this first cut does.

Two more edges to watch: a path cannot begin or end with an edge pattern, and two edge patterns cannot sit next to each other. In psql, \dG lists your graphs.

REPACK Replaces VACUUM FULL and CLUSTER

VACUUM FULL and CLUSTER have always done nearly the same job under two names that explain neither. PostgreSQL 19 unifies them into REPACK, keeping the old commands for compatibility.

REPACK [ ( option [, ...] ) ] [ table_and_columns [ USING INDEX [ index_name ] ] ]
REPACK [ ( option [, ...] ) ] USING INDEX

where option can be one of:

    VERBOSE [ boolean ]
    ANALYZE [ boolean ]
    CONCURRENTLY [ boolean ]

Plain REPACK rewrites the table with no free space beyond what fillfactor reserves, which is the old VACUUM FULL. Add USING INDEX and rows come out physically ordered by that index, which is the old CLUSTER.

REPACK listings;
REPACK listings USING INDEX listings_host_date_idx;
REPACK (ANALYZE, VERBOSE) listings USING INDEX listings_host_date_idx;

Progress lands in the new pg_stat_progress_repack view. With no table name, REPACK processes every table and materialized view you hold MAINTAIN on, which is a fine way to ruin an afternoon on a production cluster.

CONCURRENTLY Is the Reason to Care

Plain REPACK holds ACCESS EXCLUSIVE on the whole table for the duration, so on anything large it means a maintenance window. CONCURRENTLY changes that: Postgres builds the new heap and indexes while the table stays readable and writable, captures concurrent DML through logical decoding, replays it, and only then takes ACCESS EXCLUSIVE long enough to swap the files in.

REPACK (CONCURRENTLY) listings USING INDEX listings_host_date_idx;

That is what pg_repack and pg_squeeze have done as extensions for years, now in core with no triggers and no external binary. On a managed provider that will not install your extension of choice, that is the whole ballgame.

CONCURRENTLY is rejected when:

• the table is UNLOGGED
• the table is partitioned
• the table has neither a primary key nor an index-based replica identity
• the target is a system catalog or a TOAST table
• the command is inside a transaction block
• max_repack_replication_slots has no slot available

That last one is a new GUC, default 5, settable only at server start, and each concurrent repack holds a slot for its whole run. Budget it against your other slots. Temporary disk is the other cost, since DML landing during the copy is buffered to a temp file until it can be applied, so give maintenance_work_mem some room first.

The caveat worth putting in your runbook is the MVCC one, which does not apply to the non-concurrent form:

Some commands, currently only TRUNCATE, the table-rewriting forms of ALTER TABLE and REPACK with the CONCURRENTLY option, are not MVCC-safe. This means that after the truncation or rewrite commits, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the command committed.

Anything that already touched the table holds an ACCESS SHARE lock and blocks the swap, so it is safe. The exposure is a long repeatable-read or serializable transaction that took its snapshot early, has not read the table yet, and reads it after the swap commits. It sees an empty table.

Other Changes Worth Knowing

A short pass over the rest of the release that will actually touch you:

• JIT is off by default. The jit parameter now defaults to off, on the grounds that the cost-based triggering was unreliable. If you had it doing useful work, turn it back on deliberately.
• TOAST compression defaults to lz4 where the build has it, falling back to pglz otherwise. Cheaper compression and decompression on wide text and JSON columns, for the cost of slightly larger stored values.
• Autovacuum goes parallel. Workers are capped by autovacuum_max_parallel_workers, with a per-table autovacuum_parallel_workers storage parameter. A new scoring system decides which tables get processed first, tunable through autovacuum_vacuum_score_weight, autovacuum_freeze_score_weight, and three siblings.
• Planner hints, more or less. The new pg_plan_advice module adds a mini-language for pinning planner decisions: JOIN_ORDER(), HASH_JOIN(), SEQ_SCAN(), NO_GATHER() and others. Run EXPLAIN (PLAN_ADVICE) on a plan you like, then feed the generated advice back. pg_stash_advice stores and applies it per query ID.
• Upgrade landmines. RADIUS authentication over UDP is gone, successful MD5 authentication now logs a warning, max_locks_per_transaction doubles to 128, and standard_conforming_strings is forced on, so old dumps taken with it off will not load. pg_upgrade also refuses clusters holding btree_gist indexes on inet or cidr, whose default opclass changed to fix a correctness bug.

Worth the Upgrade

REPACK CONCURRENTLY is the one I will use in week one, since bloat on a high-churn table has always cost either an outage window or an extension the platform team has to bless. Property graphs I am more measured about: clean implementation, free when unused, and a two-hop pattern does beat five joins. Until the quantifiers land it will not displace a recursive CTE, and it is certainly not a substitute for a real graph database if you traverse at depth. What it does is give the SQL:2023 syntax a home so the follow-up patches have somewhere to land.