When Will Postgres 19 Be Released?

Short version: PostgreSQL 19 still does not have an announced GA date. Beta 4 shipped on September 24, 2026, and per that announcement the next planned release is the release candidate, expected in early October, with GA possibly following later in October. Neither of those is a scheduled date. The Release Management Team's stated goal is still GA "by the end of October" so the release stays inside the usual September/October window, and the source tree agrees that nothing is settled: on the REL_19_STABLE branch the release notes still carry the literal placeholder 2026-??-?? where the release date goes, and there is no release candidate tag in the repository. The project's PostgreSQL 19 Open Items page is where RC 1 and GA will get dates when they have them. If you want to test 19 today, Beta 4 is the newest beta upstream. Layerbase is skipping Beta 4 and holding out for RC 1, which we plan to add in October once it has proven stable enough to support.

Last checked 2026-09-25. I will revise this post as the dates firm up.

The reason people are asking is that 19 has slipped. PostgreSQL has shipped a major version every September or October for years, and this one is running late enough that the project is openly talking about it. 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 and the Open Items page. Nothing below is an estimate except the two rows explicitly marked as such.

The end-of-October goal in the GA row comes from 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" is doing a lot of work in that sentence, and it is written that way on purpose. Treat end of October as the earliest plausible date rather than a commitment, and do not book a maintenance window against it.

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. So an end-of-October 19 would be the latest major release in this stretch, but not by a wild margin. The project's stated intent is still to stay inside the September/October band it has kept for years.

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.

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 wave does look like it has broken. The last feature revert on the 19 branch was online data checksums on September 16. Everything committed to REL_19_STABLE since then, through the Beta 4 stamp and past it, is bug fixes, documentation and translation updates. That is what the run-up to a release candidate is supposed to look like.

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. The 19 release notes carry an "AS OF" stamp, and in the REL_19_STABLE branch that stamp now reads 2026-09-14, up from 2026-07-18 when I first wrote this. That is an improvement but it still predates the last revert, so the notes are only approximately current; the reverts themselves did strip their own release-note entries as they landed. The major-features list at the top was also rewritten on September 23 by the release team. Every item below I checked against the branch itself and the commit log rather than trusting the notes.

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. Still present and still getting active fixes as recently as this week, which is a fair description of where it sits.
• 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 clause, so FOR ALL TABLES can carve out exceptions instead of being all or nothing.
• 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.

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 beta, and bug reports filed now are worth ten filed in November.

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. Open the create flow, pick 19.0.0-beta.3 from the version picker (it carries a Beta chip so you cannot grab it by accident), and you have a hosted 19 instance with TLS and the web query console about thirty seconds later. It is otherwise a completely normal database: backups, hibernation on idle, and the free tier applies, so trying it costs nothing and does not need a card.

Upstream has moved on: Beta 4 shipped on September 24, and our picker is still on 19.0.0-beta.3, so beta 3 is what you get from us today. We are deliberately skipping Beta 4. RC 1 is expected in early October, so Beta 4 will only be the newest build for a few weeks, and every beta is a dump and restore away from the next one. Rather than make you migrate twice, we are holding out for RC 1 and will add it in October, once it has proven stable enough to support. For what a beta is actually for, running your migrations and your test suite against a 19 instance, beta 3 will tell you close to what beta 4 would. The one difference worth naming is online data checksums, which beta 3 still has and beta 4 does not, and since that feature was reverted you should not be building on it in either.

Locally. Layerbase Desktop runs the same build: create a database, pick the beta from the version list. From a terminal, the Layerbase CLI does it headless with no account needed:

npm i -g layerbase
lbase create pg19 -e postgresql --db-version 19.0.0-beta.3 --start --connect

One platform note for local runs: the 19 beta builds are macOS and Linux only right now. Stable PostgreSQL 15 through 18 runs natively on Windows, but the beta needs WSL. Expect native Windows builds once 19.0 proper lands.

Two things that will bite you if you skip them. Beta data directories are not guaranteed to carry forward, not between betas and not into GA. Moving a beta.1 database to beta.3, or a beta.3 database to 19.0, is a dump and restore, never an in-place upgrade. Plan for it now and it is a pg_dump away; plan for it in November and it is a bad afternoon. Second, the default version for new Layerbase databases is still 18, and it stays 18 until 19.0 actually ships. Nothing about your existing databases changes because a beta exists.

Here is a snippet that confirms you are actually on 19 and exercises two features I verified are still in, so it will keep working through GA:

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 the beta in CI. Not a manual poke at a psql prompt, an actual run of your migrations and your tests against a 19 instance. This is the whole value of the beta period and almost nobody does it. A throwaway beta database per CI run costs nothing and catches the incompatibility while it is still cheap to report.

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.

Do not plan a production upgrade around a date that is not firm. End of October is a goal a human being wrote on a mailing list, hedged twice in one sentence. Beta 4 shipping on time is mild evidence the schedule is under control again, and "early October" for the release candidate is still an expectation rather than a date. There is no RC 1 announcement and no press release for 19.0. When RC 1 does get announced, you have a real signal and roughly two weeks of warning. Until then, pencil in a window, do not book one, and do not tell your stakeholders that 19 ships in October.

If you want a 19 instance to point CI at while you wait, create one on Layerbase and pick 19.0.0-beta.3 from the version picker. I will keep this post updated as the schedule firms up.