When Will Postgres 19 Be Released?

Short version: PostgreSQL 19 does not have an announced GA date. The only dated milestone on the calendar right now is Beta 4 on September 24, 2026, and the Release Management Team has said its goal is GA "by the end of October" so the release stays inside the usual September/October window. That is a stated goal, not an announcement, and the project's own PostgreSQL 19 Open Items page still lists both RC 1 and GA as TBD. If you need 19 today, Beta 3 is the current beta and it runs fine for testing.

Last checked 2026-09-17. 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 Beta 4 and GA rows both come 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 beta 4 at all is a signal.

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 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, as I write this, that stamp reads 2026-07-18. They have not been regenerated since the big September reverts, so the release notes currently describe features that are no longer in the tree. Every item below I checked against the live devel documentation instead, which does rebuild nightly, plus the commit log where a revert was in question.

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 open items on it are still being worked.
• 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.
• Data checksums can be enabled or disabled on a running cluster, no re-initdb.

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.

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.

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 item I could not confirm: a widely repeated claim that the change of default_toast_compression to lz4 was reverted. I found no such revert in the commit log, and the current documentation still gives the default as lz4 where lz4 is available. Where a secondary source and the primary sources disagree, the primary sources win, so I am treating lz4 as still in. If that changes before GA I will update this post.

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.

19.0.0-beta.3 is the newest beta the PostgreSQL project has released, so our picker is current as of today. Beta 4 is scheduled for September 24 upstream. When it lands we will add it, but I am not going to promise a date for that.

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. There is no RC 1 date, and there has not been a press release. When RC 1 gets 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.