postgresql
David Sterling  

PostgreSQL 19 Beta 2 Lands with Property Graphs, Temporal SQL

The PostgreSQL Global Development Group has announced PostgreSQL 19 Beta 2, released July 16, 2026, with native SQL property-graph support, application-time (temporal) table operations, and a wave of performance and security changes. The second beta of version 19 is a feature preview ahead of general availability, which the project targets for September/October 2026. For teams on the stable line, PostgreSQL 18.4 remains the recommended release — and PostgreSQL 14 is now within sight of end of life, so this is a good moment to review upgrade plans.

PostgreSQL 19 Beta 2: What’s Inside

Two headline features stand out in the PostgreSQL 19 release notes. First, PostgreSQL 19 adds support for SQL Property Graph Queries (SQL/PGQ), the ISO-standard graph query syntax, contributed by Peter Eisentraut and Ashutosh Bapat. Property graphs are processed internally like views, so they compile down to standard relational queries — no separate graph engine required. That makes PG 19 interesting for Houston logistics and energy teams modeling supply chains, pipeline networks, and freight movements as graphs without adding another database to the stack.

Second, application-time tables mature with a FOR PORTION OF clause for UPDATE and DELETE (Paul A. Jungwirth), letting you modify only the slice of a row’s valid-time range that overlaps your target window, while “temporal leftovers” preserve the history outside those bounds. For healthcare and energy operators keeping audit-grade history, that is powerful:

-- PG 19: update only the June portion of a row's application time
UPDATE shipment_status
  FOR PORTION OF valid_period FROM '2026-06-01' TO '2026-07-01'
  SET status = 'delayed'
 WHERE container_id = 'MSKU-482113';

(Syntax per the PG 19 UPDATE documentation.)

The release notes also list ALTER TABLE ... MERGE/SPLIT PARTITIONS for partition maintenance, continued asynchronous I/O work with new worker-pool settings (io_min_workers, io_max_workers, io_worker_idle_timeout), parallel autovacuum workers (autovacuum_max_parallel_workers), online enabling of data checksums via pg_checksums, and a new pg_stat_lock view. Beta 2 itself fixes a vacuumdb --analyze-in-stages regression for partitioned tables, a REPACK worker cleanup issue on FATAL exit, an autovacuum multixact-age score calculation that could go infinite, and several bugs in the new FOR PORTION OF and SQL/PGQ code paths.

Breaking Changes to Plan For

PostgreSQL 19 also flips a few defaults worth flagging to your DBA team. Most notably, JIT compilation is now disabled by default — the optimizer-cost-based activation proved unreliable — so sites running many large analytical queries must enable it explicitly:

# postgresql.conf — PG 19: JIT is off by default; opt back in for analytics
jit = on
jit_above_cost = 100000

Security-related changes include removal of RADIUS authentication support (UDP-based, “unfixably insecure”), a warning after MD5 password logins (MD5 was already deprecated in PG 18), and a new password_expiration_warning_threshold server variable that warns users seven days before passwords expire. standard_conforming_strings is now forced on, carriage returns and line feeds are banned in database/role/tablespace names, and the MULE_INTERNAL encoding is removed. The default inet/cidr index opclass changes from the broken btree_gist to GiST, and max_locks_per_transaction defaults rise from 64 to 128. Expect pg_upgrade to flag clusters affected by several of these changes.

Stable Lineup: 18.4 Current, PG 14 Nears EOL

Per the versioning policy, PostgreSQL 18 (first released September 25, 2025) is current at 18.4 and supported through November 14, 2030; 17.10, 16.14, 15.18, and 14.23 remain supported. PostgreSQL 13 reached end of life in November 2025, and PostgreSQL 14’s final release is scheduled for November 12, 2026 — roughly three months away. The project recommends always running the current minor release of your major version; quarterly minor releases are the low-risk path to staying patched.

Ecosystem & Community: Dolt 2.0, OpenAI at 800M Users

Beyond core development, the ecosystem keeps moving. InfoQ reports that DoltHub shipped Dolt 2.0, the major update to its open-source, Git-style version-controlled SQL database, with automatic garbage collection and archive compression enabled by default — a new “archives” on-disk format that cuts storage footprint 30–50% — plus beta version-controlled vector indexes and sysbench results the team says now beat MySQL. Dolt’s Postgres-compatible sibling, DoltgreSQL, remains in beta, which teams building versioned data pipelines in Houston’s energy and healthcare sectors will want to watch.

And in January, OpenAI published how it scales PostgreSQL to power 800 million ChatGPT users — a striking proof point that Postgres remains the default choice even at the frontier of AI infrastructure.

Finally, the 19 cycle needs you. The project explicitly asks the community to run typical workloads against Beta 2, review the open issues list on the wiki, and submit bugs — feedback that decides how quickly release candidates follow. Whether you are planning a temporal-schema migration, a graph model, or just a JIT decision, the next few months of testing will shape the final release.

Leave A Comment