--- title: What's new in PostgreSQL 19 | daily.dev description: PostgreSQL 19 Beta 3 shipped August 13, 2026, with GA expected September or October. Notable compatibility breaks include JIT disabled by default, removal of... canonical: https://daily.dev/posts/what-s-new-in-postgresql-19-loq0z6h4n twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: What's new in PostgreSQL 19 | daily.dev og:description: PostgreSQL 19 Beta 3 shipped August 13, 2026, with GA expected September or October. Notable compatibility breaks include JIT disabled by default, removal of... og:url: https://daily.dev/posts/what-s-new-in-postgresql-19-loq0z6h4n og:image: https://api.daily.dev/og/posts/LoQ0Z6h4N.png og:image:alt: What's new in PostgreSQL 19 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # What's new in PostgreSQL 19 **[Collections](https://daily.dev/sources/collections)** · 4 min read · 34 upvotes · 0 comments ## Summary PostgreSQL 19 Beta 3 shipped August 13, 2026, with GA expected September or October. Notable compatibility breaks include JIT disabled by default, removal of RADIUS authentication, always-on standard_conforming_strings, GiST inet/cidr opclass changes requiring REINDEX, a doubled max_locks_per_transaction default, and default_toast_compression switching from pglz to lz4. The ALTER TABLE MERGE/SPLIT PARTITIONS feature was reverted on August 27 after it was found to silently drop CHECK constraints and break logical replication, though release notes drafts still mention it. New SQL features include FOR PORTION OF for temporal updates, INSERT ... ON CONFLICT DO SELECT ... RETURNING, IGNORE NULLS for window functions, alterable CHECK constraint enforcement, a unified REPACK command replacing VACUUM FULL and CLUSTER, DDL-dumping catalog functions, and an initial SQL/PGQ graph-pattern implementation. Four new system views — pg_stat_lock, pg_stat_recovery, pg_stat_autovacuum_scores, and pg_dsm_registry_allocations — improve visibility into lock contention, recovery state, autovacuum prioritization, and dynamic shared memory usage. ## Content ## Where things stand PostgreSQL 19 Beta 3 shipped August 13, 2026. General availability is expected sometime in September or October, following the project's usual cadence. But the last few weeks have been unusually turbulent, and if you're planning an upgrade, there's more to track than a typical release. ## Two features were pulled from the branch **SQL/PGQ property graphs** was reverted on September 7, removing 47 commits. **ALTER TABLE MERGE/SPLIT PARTITION** was reverted on August 27, removing 14 commits. Both were pulled after unresolved design issues surfaced. The MERGE/SPLIT PARTITION problems were concrete: silently dropped CHECK constraints, incorrectly recomputed generated columns, phantom logical-replication inserts, and publications quietly emptying. The official release notes still listed the feature at the time of writing, so don't rely on those as a source of truth right now. Both reverts followed a pgsql-hackers thread where Robert Haas asked Claude to rank PostgreSQL 19 features by post-freeze bug fix count, then posted the top six and asked which should be pulled before release: - RI fast-path FK batching (~16 fixes) - REPACK CONCURRENTLY (28 fixes, scope cut to one repack per cluster) - Online data checksums (~25 fixes) - UPDATE/DELETE FOR PORTION OF (17 fixes, 3 security-related) - SQL/PGQ property graphs (17 fixes) - postgres_fdw stats import (7 fixes) The thread got heated. Tom Lane and Andres Freund wanted PGQ out - it still needed catalog version bumps and had security bugs reachable by any user. Daniel Gustafsson offered to revert online checksums within 90 minutes; others pushed back. The core debate: are LLMs just surfacing bugs earlier than usual, or are these features genuinely undercooked? Melanie Plageman put it plainly: "bad alternatives aren't the bar for core." Andres added: "incremental development is a virtue." Bruce Momjian called the situation unprecedented. Joshua Drake proposed slipping the release to spring 2027. Meanwhile, at least one contributor started using AI tooling to find bugs and propose fixes for the flagged features, focusing on improving the verification harness rather than manually processing each result. The three remaining features on Haas's list - FOR PORTION OF, online checksums, and postgres_fdw stats import - have varying levels of activity. REPACK had its scope narrowed rather than its bugs fixed. ## Compatibility breaks worth knowing about Before upgrading, these changes will require attention: - **JIT disabled by default** - it was misfiring on OLTP queries whose cost estimates hovered near the `jit_above_cost` threshold - **`standard_conforming_strings` always on** - no longer configurable - **RADIUS authentication removed** - **MD5 login warnings** added - **inet/cidr GiST opclasses changed** - requires a reindex - **CR/LF disallowed in object names** - **`max_locks_per_transaction` doubled** from 64 to 128 - **Default TOAST compression switches** from pglz to lz4 ## What's actually new and stable Despite the noise, there's real substance here. **REPACK command** lands in core, replacing the need for the pg_repack and pg_squeeze extensions when compacting bloated tables. `REPACK CONCURRENTLY` rewrites a table online, holding only a brief exclusive lock during the final swap. It's not MVCC-safe and requires `wal_level` and a primary key, and its scope was narrowed during the beta cycle - but it's in. **New SQL syntax:** - `INSERT ... ON CONFLICT DO SELECT ... RETURNING` for idempotent upsert-and-fetch - `IGNORE NULLS` for window functions - `GROUP BY ALL` - `FOR PORTION OF` for temporal splits (still in the branch as of writing) - `range_minus_multi()` / `multirange_minus_multi()` - `random()` over dates and timestamps - `error_on_null()` - Enforceable and un-enforceable CHECK constraints **Planner improvements:** - Eager aggregation - pre-aggregates rows before a join - Faster anti-join path for NOT IN - `pg_plan_advice` for pinning query plans - Faster foreign-key inserts **Four new system views:** - `pg_stat_lock` - cumulative cluster-wide lock statistics by lock type - `pg_stat_recovery` - a single atomic snapshot of standby replication state - `pg_stat_autovacuum_scores` - exposes the new score-based autovacuum prioritization, which replaces the old pg_class-order processing - `pg_dsm_registry_allocations` - shows dynamic shared memory used by extensions **Other changes:** `log_lock_waits` enabled by default, parallel autovacuum, wider MultiXact offsets, catalog-native DDL dump functions. ## What to do now If you're planning an upgrade, the safest path is to target PostgreSQL 18 and wait for PostgreSQL 19's first minor releases before moving. The feature set is still shifting, the release notes don't reflect recent reverts, and at least three more features are under active scrutiny. One hard deadline to keep in mind: **PostgreSQL 14 reaches end of life on November 12, 2026**. If you're still on 14, that's the more urgent upgrade to plan. ## Questions this post answers ### What breaking changes does PostgreSQL 19 introduce that I need to check before upgrading? PostgreSQL 19 disables JIT by default, removes RADIUS authentication entirely, makes standard_conforming_strings permanently on, requires a REINDEX after GiST inet/cidr opclass changes, doubles the default max_locks_per_transaction, and switches default_toast_compression from pglz to lz4 for new toast values. Existing data is unaffected by the compression change, but memory usage may rise slightly due to the locks default. _Track PostgreSQL upgrade breaking changes like these on daily.dev before rolling out a major version._ ### Is the ALTER TABLE MERGE/SPLIT PARTITIONS feature included in PostgreSQL 19? No, it was reverted from the PostgreSQL 19 branch on August 27 after reviewers discovered it could silently drop CHECK constraints, mis-recompute generated columns, and break logical replication. Despite the revert, the official release notes draft still described the feature at the time, so it's worth verifying against the actual GA release rather than trusting the draft notes. _Developers planning partition strategies can follow PostgreSQL 19 release changes on daily.dev before GA._ ### What does the new pg_stat_autovacuum_scores view in PostgreSQL 19 show? It exposes the per-table scoring system that determines autovacuum processing order, based on XID age, multixact age, dead tuple count, insert volume, and analyze staleness. Previously, administrators could see that autovacuum ran but not why it prioritized one table over another; this view makes that prioritization queryable directly. _Database engineers tuning autovacuum behavior can follow PostgreSQL observability updates on daily.dev._ ## Similar posts on daily.dev - [PostgreSQL 19 Beta Introduces SQL Graph Queries and Concurrent Table Repacking](https://daily.dev/posts/postgresql-19-beta-introduces-sql-graph-queries-and-concurrent-table-repacking-2adopzbmz) · InfoQ · 91 upvotes · 4 comments --- Tags: [#database](https://daily.dev/tags/database), [#sql](https://daily.dev/tags/sql), [#postgresql](https://daily.dev/tags/postgresql), [#observability](https://daily.dev/tags/observability) [View this post on daily.dev](https://daily.dev/posts/what-s-new-in-postgresql-19-loq0z6h4n) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"What's new in PostgreSQL 19","url":"https://daily.dev/posts/what-s-new-in-postgresql-19-loq0z6h4n","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/what-s-new-in-postgresql-19-loq0z6h4n"},"datePublished":"2026-09-08T15:50:24.552Z","dateModified":"2026-09-15T01:23:39.887Z","description":"PostgreSQL 19 Beta 3 shipped August 13, 2026, with GA expected September or October. Notable compatibility breaks include JIT disabled by default, removal of...","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/what-s-new-in-postgresql-19-loq0z6h4n","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":34},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,sql,postgresql,observability","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"What's new in PostgreSQL 19"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/what-s-new-in-postgresql-19-loq0z6h4n#faq","mainEntity":[{"@type":"Question","name":"What breaking changes does PostgreSQL 19 introduce that I need to check before upgrading?","acceptedAnswer":{"@type":"Answer","text":"PostgreSQL 19 disables JIT by default, removes RADIUS authentication entirely, makes standard_conforming_strings permanently on, requires a REINDEX after GiST inet/cidr opclass changes, doubles the default max_locks_per_transaction, and switches default_toast_compression from pglz to lz4 for new toast values. Existing data is unaffected by the compression change, but memory usage may rise slightly due to the locks default. Track PostgreSQL upgrade breaking changes like these on daily.dev before rolling out a major version."}},{"@type":"Question","name":"Is the ALTER TABLE MERGE/SPLIT PARTITIONS feature included in PostgreSQL 19?","acceptedAnswer":{"@type":"Answer","text":"No, it was reverted from the PostgreSQL 19 branch on August 27 after reviewers discovered it could silently drop CHECK constraints, mis-recompute generated columns, and break logical replication. Despite the revert, the official release notes draft still described the feature at the time, so it's worth verifying against the actual GA release rather than trusting the draft notes. Developers planning partition strategies can follow PostgreSQL 19 release changes on daily.dev before GA."}},{"@type":"Question","name":"What does the new pg_stat_autovacuum_scores view in PostgreSQL 19 show?","acceptedAnswer":{"@type":"Answer","text":"It exposes the per-table scoring system that determines autovacuum processing order, based on XID age, multixact age, dead tuple count, insert volume, and analyze staleness. Previously, administrators could see that autovacuum ran but not why it prioritized one table over another; this view makes that prioritization queryable directly. Database engineers tuning autovacuum behavior can follow PostgreSQL observability updates on daily.dev."}}]} ```