PostgreSQL 19 Beta 2 Released: Native Graph Queries, Unified REPACK, and Feature Freeze
The second pre-release brings SQL/PGQ support and zero-downtime table reorgs as the PostgreSQL Global Development Group locks down features for stability testing.
PostgreSQL 19 Beta 2 is out now. The PostgreSQL Global Development Group has shifted the project's focus entirely to regression testing, bug fixing, and stability improvements. This release is feature-frozen. No new features are being added during the beta period. The community of 725+ contributors is now dedicated to hardening the code ahead of the final release.
If you're counting days, the end of the road is still far off. The project is targeting a GA window around September or October 2026. That's a long lead time for a database release, giving the team plenty of opportunity to squash issues, but it also signals a measured approach to shipping.
Graph Queries and Table Surgery
The headline features in Beta 2 might not be new additions since the feature freeze, but they represent significant shifts in how you'll interact with data. The most prominent is native support for the SQL/PGQ standard.
PostgreSQL 19 adds built-in graph data modeling and querying capabilities. You'll get the GRAPH_TABLE function and CREATE PROPERTY GRAPH commands directly in the server. Internally, these are processed like views and written as standard relational queries. You no longer need to rely solely on extensions for graph operations. This brings the database squarely into the property graph conversation without requiring a separate stack.
The REPACK command is another major consolidation. It replaces both VACUUM FULL and CLUSTER. These two commands have caused confusion for years, often sharing similar downsides regarding table locking and bloat handling. REPACK unifies them under one interface.
Crucially, REPACK supports a CONCURRENTLY option. Tables can be repacked without acquiring access-exclusive locks. This enables zero-downtime table reorganization. The new server variable max_repack_replication_slots lets you control replication usage during these operations.
Partition management also gets better. ALTER TABLE ... MERGE PARTITIONS and ALTER TABLE ... SPLIT PARTITIONS allow direct manipulation of partition structures. You can merge multiple partitions into one or split a partition into sub-partitions without the complex workarounds previously required.
Other notable additions include:
- FOR PORTION OF clause for temporal table operations on specific time ranges.
- IGNORE NULLS support in window functions like lead(), lag(), and first_value().
- INSERT ... ON CONFLICT DO SELECT ... RETURNING to handle conflicts by returning rows.
- GROUP BY ALL to automatically group non-aggregate expressions.
- COPY TO JSON format with FORCE_ARRAY support.
Performance Shifts and the JIT Switch
The performance improvements are substantial, though some come with configuration changes you need to watch.
JIT is now disabled by default. The project deemed cost-based activation unreliable for general use. If you run large analytical queries that depend on JIT for performance, you must manually enable it. This is a breaking change for workloads that assumed JIT would be active.
The default TOAST compression has shifted from pglz to lz4. This offers more efficient compression for column storage. It's a win for space savings and throughput, though you should verify your benchmarks if compression characteristics matter heavily to your latency profile.
The optimizer is getting smarter about join elimination. NOT IN clauses are converted to more efficient ANTI JOINs when NULLs are absent. The memoize support for ANTI JOINs with unique inner sides is new. Aggregate processing can now occur before joins to reduce row counts earlier in the plan.
Autovacuum also improves significantly. It can now use parallel workers, controlled by the autovacuum_max_parallel_workers GUC. A new granular scoring system determines table processing order based on weights like autovacuum_freeze_score_weight and autovacuum_vacuum_score_weight.
Async I/O read-ahead scheduling has been tuned for large requests. The io_method_worker auto-controls background workers to balance load. Table scans can now mark pages as all-visible in the visibility map, a capability previously limited to VACUUM and COPY FREEZE.
Security changes are aggressive. MD5 password authentication now issues a warning on success. MD5 was already deprecated in PostgreSQL 18. RADIUS authentication has been removed entirely because the protocol support over UDP is considered unfixably insecure.
Database and role names can no longer contain carriage returns or line feeds. This is a security fix. pg_upgrade will refuse clusters with such names. The project is also adding password_expiration_warning_threshold, which defaults to 7 days, to warn about expiring credentials.
Upgrade Traps and Breaking Changes
Migrating to Beta 2 requires care. Several defaults and behaviors have shifted in ways that can break existing setups.
standard_conforming_strings is forced ON. Dumps created with standard_conforming_strings = off in pre-v19 versions will not load properly. You must use a PostgreSQL 19+ pg_dump or set the variable explicitly on import.
The default index opclass for inet and cidr changed from btree_gist to GiST. The old opclass is broken and can exclude rows that should be returned. pg_upgrade will refuse clusters with btree_gist inet/cidr indexes. You'll need to fix these indexes before upgrading.
max_locks_per_transaction default moved from 64 to 128. Lock size allocation has changed. If you relied on the previous default, you may need to double your settings to match capacity.
MULE_INTERNAL encoding is removed. Databases using this encoding must be dumped and restored with a different encoding. pg_upgrade won't touch them.
System columns can no longer be used in COPY FROM ... WHERE. The values were not well-defined. READ ONLY transactions via postgres_fdw can no longer modify rows through the foreign data wrapper.
Monitoring gets new visibility. pg_stat_lock provides per-lock-type statistics. pg_stat_autovacuum_scores exposes the granular scoring details. Early warnings for transaction ID wraparound now trigger when the count drops below 100 million, up from the previous 40 million threshold.
log_lock_waits is enabled by default. You'll see more log output regarding lock waits. log_min_messages now supports per-process-type levels in the format type:level.
Testing the Waters
PostgreSQL strongly advises against using beta versions in production. Beta testing should focus on running typical application workloads and using your existing testing tools.
The project has listed several open items for Beta 2. These include concurrent REPACK lock upgrade behavior, FOR PORTION OF interactions with Row Level Security, and sequence sync worker races. If you're running the beta, check the open items list before diving in.
The date for the final release remains distant. With a target of late 2026, this is a project for the long haul. Beta 2 gives you a snapshot of the direction and the features, but stability will only come after months of further testing and release candidates.
Head here to download the Beta 2 source code. Check the release notes for full details on every change. Submit bugs at the PostgreSQL account portal if you find issues.
