When Will Postgres 19 Be Released?

PostgreSQL 19 RC 2 shipped on November 12, 2026. General availability remains planned for November 19, unless another issue requires a delay or another candidate. RC 2 is the current upstream build to test; it is still a prerelease.

Last checked November 12, 2026. Layerbase's public PostgreSQL picker currently lists 18 and 19.0.0-beta.3, not RC 2 or 19.0. The 18 label does not identify its patch release, so it does not establish that 18.7 is deployed. The upstream GA target is not a commitment to same-day Layerbase availability.

What changed in RC 2

The announcement calls out fixes for GROUPING SETS, IGNORE NULLS window functions, eager aggregation, and standby promotion. Earlier prerelease testing is not a substitute for testing the candidate.

If you used JSON_ARRAY() or JSON_OBJECT() over arrays, composite types, or ranges in expression indexes, generated columns, or partition keys, review those objects before upgrading: RC 2 reverses their eligibility there, and affected definitions must be dropped or rewritten. For pg_upgrade, also check the release notes' reindex requirements for full-text search, pg_trgm, and fuzzystrmatch indexes.

Use the Migration to Version 19 notes to plan your own upgrade. Test on a disposable copy before touching production.

The reason people are asking is that 19 has slipped, twice. PostgreSQL has shipped a major version every September or October for a decade, this one spent the summer reverting features, and the GA target has now moved out of that window entirely. What follows is the dated timeline, why the slip happened, what is still in the release, what has been pulled out, and how to actually get your hands on 19 before it ships.

What has actually been announced

Here is every milestone with a date attached, from the release announcements, the hackers list and the PostgreSQL 19 Open Items page. Nothing below is my estimate: the remaining future GA row is a date the project has published, and the project can still move it.

November 19 is the third date this cycle has carried, so the trail is worth walking. It starts with Jonathan Katz's September 3 message to pgsql-hackers, which is worth quoting directly because the wording matters:

You may notice that we're doing a Beta 4 a bit later than normal this year. This is primarily due to handling the influx of issues that have been reported that have taken additional time to handle. The current goal is to try to get PostgreSQL 19 to GA by the end of October so we can try to stay on our usual schedule of being within the Sept/Oct timeframe for GA.

"The current goal is to try" was doing a lot of work in that sentence, and it was written that way on purpose. On September 28 the team put real dates behind the goal: RC 1 on October 15 and GA on October 29, with no second candidate. RC 1 held, to the day. GA did not. The October 10 update moved it to November 19 and inserted RC 2 on November 12, and that is the schedule the RC 1 announcement carries.

So the end-of-October goal missed by three weeks, and what actually stretched is the gap between the first candidate and the release: two weeks as planned in September, five weeks as scheduled now. That is the shape of a team that has decided it would rather be late than ship the thing twice.

How late is this, historically

Every first-release date below is from the project's own versioning policy page.

Four of the last six landed in the back half of September. The outlier is 15, which arrived on October 13 after its own schedule trouble. A November 19 release does not just set a new late record for this stretch, it leaves the September/October band the project has kept for a decade. The team spent most of the cycle trying to stay inside that window, said so in public, and in the end took the later date over the shakier one.

Notice also that there were only three betas for most of those cycles. A fourth beta at all is a signal, and 19 got one; a second release candidate is rarer still, and 19 has now had that too.

Why it is late

The short answer is that a lot of things committed just before the April freeze turned out not to be ready, and finding that out took the whole beta period.

Postgres runs on a one-way cliff: a feature either lands before the freeze or waits a year. That creates enormous pressure to commit in the last days of the last CommitFest, which is exactly when a patch has the least review behind it. Several of 19's headline features went in that way, and post-commit review over the summer found design-level problems rather than ordinary bugs. A bug you fix. A design problem you either fix properly, which takes a release cycle, or you revert.

The project chose to revert, repeatedly, and it kept choosing that through mid-September. Christophe Pettus wrote a good post-mortem of the pattern on September 14, and Snowflake published a tally of the reverts that counts 53 revert commits across the cycle. I have not independently reproduced that count, so treat the number as their tally; the individual reverts below I did verify against the commit log.

The earlier history below was checked through RC 1. RC 2 adds a later reversal affecting JSON expressions, described above, so the absence of a broad feature revert does not mean every prerelease schema definition remains valid.

The important thing to take from it is what the reverts mean. A release that pulls a feature in September is a release doing its job. The alternative was shipping SQL/PGQ with a design nobody was happy with and living with it for five years of support.

What is still in PostgreSQL 19

One caution before the list, though a smaller one than last month. The 19 release notes carry an "AS OF" stamp, and at the REL_19_RC1 tag that stamp reads 2026-10-09, up from 2026-09-14 in September and 2026-07-18 when I first wrote this. It is now past every revert in the cycle, so the notes are current in a way they were not before. The major-features list at the top was rewritten on September 23 by the release team and still stands. Every item below I checked against the release notes at the RC 1 tag and the commit log, not against a summary.

SQL and developer features

• INSERT ... ON CONFLICT DO SELECT ... RETURNING. Get-or-create in one statement, with the conflicting row returned instead of an error, and optionally locked with FOR UPDATE or FOR SHARE. Still documented in the INSERT reference.
• IGNORE NULLS and RESPECT NULLS on window functions, covering lead(), lag(), first_value(), last_value() and nth_value().
• COPY TO can emit JSON, including a single array via the FORCE_ARRAY option.

Performance

• Faster foreign key checks, via the batched RI fast path. This one is worth stating plainly because a secondary write-up I read suggested it had been pulled: it has not. The commit log for September shows fixes to it (snapshot ordering, collation mismatch fallback), not a revert, and it kept taking fixes right up to Beta 4 (permission checks, operator family invalidation). It is in, and "quicker foreign-key checks" is still in the release notes' own summary of the release.
• io_method = worker now scales its worker pool automatically between io_min_workers and io_max_workers instead of running a fixed count, with io_worker_idle_timeout and io_worker_launch_interval controlling the ramp.
• pg_plan_advice and its companion pg_stash_advice, a supported way to stabilize planner decisions for a query rather than fighting the planner with enable_* flags.

Maintenance and vacuum

• REPACK, in core, doing what VACUUM FULL and CLUSTER did plus a CONCURRENTLY mode that keeps reads and writes flowing until the final swap. It leads the release team's own major-features list, and it absorbed fixes right up to the candidate: dropped-column values are now cleared during a concurrent repack (October 3, October 7) and its documentation page was rewritten on October 7. A feature taking that many fixes in the last fortnight is worth testing rather than assuming.
• Parallel autovacuum, capped by autovacuum_max_parallel_workers, along with a scoring system that prioritizes the tables that most need attention instead of taking them in discovery order. The release team lists this pair as one of the headline features of 19.

Replication and monitoring

• WAIT, a new command that blocks until a standby has replayed up to a chosen LSN, which is what you want for read-your-writes against a replica. Note the name: it was committed as WAIT FOR and renamed to WAIT in the documentation on September 14, so older write-ups will call it the wrong thing.
• CREATE PUBLICATION and ALTER PUBLICATION accept an EXCEPT TABLE clause, so FOR ALL TABLES can carve out exceptions instead of being all or nothing. Note the final spelling: the clause was renamed about a week before the feature freeze, so older write-ups show it without the TABLE.
• Logical replication of sequence values. Sequences were the long-standing hole in logical replication, and a failover that left yours behind made for a genuinely bad afternoon.
• Logical replication can be turned on without restarting the server, provided wal_level is already replica. This and the sequence work both sit on the release team's own major-features list, so they are not going quietly.

Defaults that changed

These two are the ones to actually test against, because they change behavior on an existing schema without you asking.

• jit now defaults to off. The docs are blunt about why: the cost model that decided when to JIT "has been determined to be unreliable." If you benchmarked a query on 18 with JIT firing, it will not fire on 19 until you turn it back on.
• default_toast_compression now defaults to lz4, with a caveat: the current docs say "the default is lz4 (if available); otherwise, pglz", and availability means the build was compiled with lz4 support. Check the value on your actual server rather than assuming, especially if you build Postgres yourself.

What is now expected to be out

Each of these was committed for 19 and has since been reverted. All of them are verifiable in the commit log, and none of them will be in 19.0.

Online enabling and disabling of data checksums. Turning checksums on or off on a running cluster, no re-initdb and no dump and restore. I had this in the "still in" list when I first published this post. That was wrong: it was reverted on September 16, the day before, unwinding thirty commits. The commit message is unusually direct about why, and the reasoning is worth reading if you want to understand this whole release cycle:

The feature to enable, or disable, data checksums in an online cluster saw a number of postcommit fixes during the beta period. Suspicions were raised about the risk of more issues surfacing after GA. To avoid shipping code which may have bugs, this reverts in full, or in part, the following commits

Two small pieces were kept on their own merit: a fix for offline checksums not preserving initial state in pg_control_init, and an extra line in page-verification logging that says whether the buffer will be zeroed. The feature itself is gone, and the release notes no longer mention it. If you were waiting on 19 to turn checksums on without rebuilding the cluster, you are waiting on 20.

pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl(). Server-side functions that emit the CREATE statement for a role, a tablespace or a database, which would have made cluster-level objects scriptable without shelling out to pg_dumpall. Reverted September 12, taking the twelve follow-up commits it had already accumulated with it.

SQL/PGQ property graph queries. The SQL standard's graph query syntax, letting you declare a property graph over existing tables and pattern-match across it with GRAPH_TABLE. This was the single biggest feature in the release and the revert was correspondingly large, 124 files and around 16,000 lines removed on September 7. The reasons were readiness and design rather than any one bug. The work is not abandoned, but a feature of that size restarting after a revert is not a safe bet for 20 either.

ALTER TABLE ... MERGE/SPLIT PARTITION(S). Declarative partition reshaping without hand-rolling a detach, create, move, attach dance. Reverted August 26 with the commit message citing "multiple design issues which are too late to address in this release cycle." That phrasing suggests a return once the design settles, but it has now missed two cycles.

UPDATE/DELETE ... FOR PORTION OF. The temporal DML half of the SQL:2011 period support, where updating a row for part of its validity period automatically splits it and keeps the leftovers. Reverted September 15, and the revert had to unwind 23 commits, which tells you how much fixing it had already absorbed. PostgreSQL 18's WITHOUT OVERLAPS temporal constraints are unaffected and still there.

GROUP BY ALL. Shorthand for grouping by every non-aggregated select-list column, the thing DuckDB and Snowflake users keep asking for. Reverted July 17 after post-commit review found it missed the special handling for entries that also appear in ORDER BY, producing wrong results with non-default equality semantics. The commit message says outright: "We'll revert and try again in v20." Of everything on this list, this is the most likely to come back.

Non-text output formats for pg_dumpall. Directory and custom format dumps of a whole cluster, which would have made pg_dumpall parallel-restorable like pg_dump already is. Reverted June 18, early enough that most beta write-ups never mentioned it.

Provider-specific identifier casefolding. A pair of changes meant to stop identifier case handling depending on the process-wide libc locale. Reverted September 11 along with the related change that forced LC_COLLATE to C in the postmaster, after an unintended behavior difference turned up for the builtin provider. Invisible to almost everyone, but if you were counting on 19 to fix locale-dependent identifier folding, it does not.

CREATE SCHEMA subcommand expansion. Support for more object types inside a CREATE SCHEMA block, plus the reordering work that went with it, both reverted September 11. Unrelated CREATE SCHEMA work did survive: forward references in FOREIGN KEY clauses inside a CREATE SCHEMA block are in 19.

Letting logical decoding plugins declare they do not read shared catalogs. The smallest item here and the last to be tidied up. This is the one entry where I am linking the cleanup rather than the revert: the release team deleted the release-note line on October 12, three days before RC 1, and that commit message is what states the underlying commit had been reverted. I could not find the revert itself in the branch log, so take the fact from upstream rather than from me. Either way the feature is not in 19, and if you read the 19 notes before October 12, that line was stale.

One loose end from the first version of this post, now closed. A widely repeated claim held that the switch of default_toast_compression to lz4 had been reverted. There is a revert in the log, and it is not the one people meant. The first attempt landed on March 4, was reverted the next day, and was re-landed the same day as "take two". The second version is the one in the tree, and the configuration docs on the branch still read "The default is lz4 (if available); otherwise, pglz." So lz4 is in, and the rumor is a half-memory of a revert that lasted about a day in March.

There is one wrinkle worth knowing, because it trips people up when they go looking. postgresql.conf.sample ships with #default_toast_compression = pglz, which looks like a contradiction. It is not: the sample file cannot be conditional on build options, so initdb rewrites that value in place when the build has lz4 support. Read the setting off a running server, not out of the sample file.

How to run PostgreSQL 19 today

You do not have to wait for GA to find out whether your app survives 19. That is the entire point of a pre-release, and bug reports filed now are worth ten filed after it ships.

I run Layerbase, which hosts PostgreSQL among other engines, so treat this section as the vendor part of the post. Everything above stands on its own.

Layerbase Cloud. The create flow offers 19.0.0-beta.3, labeled Beta, alongside the default 18 option. PostgreSQL is available on Free with idle sleep; scheduled backup retention depends on the plan. Use this older preview only when it suits the specific behavior you are testing.

That is the public picker state checked on November 12, not a claim that beta 3 contains the RC 2 fixes. Test the current candidate using the upstream downloads when evaluating readiness for GA. Beta 3 includes features and behavior that changed later in the cycle, so passing tests on it does not validate the final release.

Use disposable databases for prerelease testing. Keep a logical export and follow the upstream upgrade instructions for the exact source and target builds; do not assume a beta data directory can be reused with a release candidate. A candidate being available upstream does not upgrade any existing Layerbase database.

Here is a small compatibility probe. Read the exact server build first; this does not replace testing your application migrations and queries:

SELECT version();

SHOW jit;                        -- expect: off  (this is new in 19)
SHOW default_toast_compression;  -- expect: lz4  (pglz if built without lz4)

CREATE TABLE tags (
  id   bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name text NOT NULL UNIQUE
);

-- ON CONFLICT DO SELECT: run this twice, get the same id both times,
-- with no dead tuple and no second round trip
INSERT INTO tags (name) VALUES ('postgres')
ON CONFLICT (name) DO SELECT
RETURNING id, name;

If the second INSERT returns the existing row instead of raising a syntax error, you are on 19. On 18 and earlier the parser rejects DO SELECT outright.

For more on what is in the beta and how it behaves, see Postgres 19 Beta is live on Layerbase. For the version you are probably actually running, What's New in PostgreSQL 18 covers uuidv7(), virtual generated columns, and skip scan.

What to do between now and GA

Three things, in order of how much they will save you.

Run your test suite against RC 2 in CI. Not a manual poke at a psql prompt, an actual run of your migrations and your tests against a 19 instance. Use an isolated test database and include the upgrade path from the version you run today.

Check the two changed defaults explicitly. jit off and default_toast_compression on lz4 are the changes most likely to alter behavior without an error message. JIT going off can change the shape of a query plan you benchmarked; on most workloads it makes things faster, which is why the default changed, but "most" is not "yours." Read them off your own server with the SHOW statements above rather than trusting a blog post, including this one.

Plan around November 19, but keep the upgrade conditional. RC 2 arrived on schedule. That is useful evidence, not a guarantee of the GA date or proof that your application is ready. Wait for the final release announcement and validate your backup and restore procedure before scheduling a production upgrade.

Layerbase's create page shows the builds currently offered. As checked above, its prerelease option is beta 3. This post now reflects RC 2; the next update will follow the GA announcement and a fresh check of hosted availability.