Postgres 19 Beta is live on Layerbase

The PostgreSQL project released 19 Beta 1 on June 4, and as of today you can run it on Layerbase. Open the create flow, pick 19.0.0-beta.1 from the version picker (it wears a Beta chip so you can't grab it by accident), and you have a hosted 19 instance with TLS and the web query console about thirty seconds later.

The default for new databases is still PostgreSQL 18, and it will stay 18 until 19.0 actually ships. The beta is opt-in, every surface that shows the version shows the Beta chip next to it, and nothing about your existing databases changes.

Why bother with a beta

Because September is a bad time to find out your app breaks on 19.

Major PostgreSQL versions occasionally change behavior your code quietly depends on, and 19 has a couple of defaults worth checking: JIT compilation is now off by default, and default_toast_compression switched to lz4. Neither is likely to break you, but "likely" is doing some work in that sentence, and the whole point of a beta is replacing "likely" with "verified". Point a staging branch of your app at a 19 instance, run your migrations and your test suite, and you'll know.

There's also plenty in 19 worth being genuinely excited about. Every example below runs as-is on a Layerbase 19 instance in the web query console.

ON CONFLICT DO SELECT: get-or-create in one statement

My favorite of the release. Everyone has written the get-or-create dance: insert a row, and if it already exists, fetch the existing one. Before 19 that meant either the DO UPDATE SET name = EXCLUDED.name hack (a pointless write that generates a dead tuple just to make RETURNING fire) or a two-statement round trip with a race window. Now the database just does the thing you meant:

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

INSERT INTO tags (name) VALUES ('postgres')
ON CONFLICT (name) DO SELECT
RETURNING id, name;

Run it once and the row is inserted. Run it again and instead of an error or silence, you get the existing row back:

 id |   name
----+----------
  1 | postgres
(1 row)

Same id both times, no dead tuple, no race. Two details to know: RETURNING is required (a DO SELECT that returns nothing would be pointless, and the parser agrees), and you must name the conflict target. There's also DO SELECT FOR UPDATE when you want the returned row locked because an update is coming next.

REPACK: table rewrites without the extension

Rewriting a bloated table used to be a choice between VACUUM FULL and CLUSTER, both of which take an access-exclusive lock and block everything until they finish, or installing pg_repack as an extension. PostgreSQL 19 pulls that into core as a single command that covers both jobs:

-- rewrite the table, then update planner stats
REPACK (CONCURRENTLY, ANALYZE) orders;

-- or rewrite it physically ordered by an index, like CLUSTER
REPACK (CONCURRENTLY) orders USING INDEX orders_created_at_idx;

With CONCURRENTLY, reads and writes keep flowing while the rewrite happens; the exclusive lock is only taken at the very end, for the moment it takes to swap the old files for the new ones. On a managed platform this matters because you don't get to schedule a maintenance window on someone else's Saturday: reclaiming a few gigabytes of bloat becomes something you can just run.

Parallel autovacuum

Manual VACUUM (PARALLEL n) has existed since 13, but autovacuum, the thing that actually does the vacuuming in real life, was stuck single-threaded per table. In 19, autovacuum can use parallel workers on large tables, capped by a new setting:

autovacuum_max_parallel_workers = 4

Alongside it, a new prioritization model scores tables by how badly they need attention instead of processing them in whatever order they turn up. If you've ever watched a genuinely bloated table wait in line behind trivial ones, this pair is the fix.

Smaller things you'll feel anyway

• Foreign key checks up to 2x faster. Free performance on write-heavy schemas with lots of references; nothing to configure.
• Async I/O grows up. Building on 18's async I/O subsystem, io_method=worker now scales its worker count automatically between io_min_workers and io_max_workers instead of using a fixed count.
• Online data checksums. Enable or disable checksums without re-initializing the cluster.
• COPY TO can emit JSON. Native JSON output for exports, no more piping through row_to_json gymnastics.

The full release announcement has the rest; it's a list of over 200 changes.

The obligatory beta warning

A beta is a beta. The PostgreSQL project does not guarantee that a Beta 1 data directory survives into later betas or the final release, so treat a 19 instance as disposable: schema migrations, test suites, benchmarks, and compatibility checks, not the customer table. Keep production on 18, where it's happy.

On Layerbase the beta instance is otherwise a completely normal database: TLS, the web query console, hibernation on idle, and the free tier applies, so kicking the tires costs nothing.

Running it locally

If you'd rather test on your own machine, Layerbase Desktop runs the same 19.0.0-beta.1 build locally: create a database, pick the beta from the version list, done. Prefer a terminal? SpinDB does the same thing headless:

npm i -g spindb
spindb create pg19 -e postgresql --db-version 19.0.0-beta.1 --start --connect

One platform note: the 19 beta builds are macOS and Linux only for now. Stable PostgreSQL (15 through 18) runs natively on Windows, but to try the 19 beta on a Windows machine you'll need WSL installed and to run it from there. As with every stable major, expect native Windows builds once 19.0 proper lands.

What happens at GA

PostgreSQL 19.0 is expected in the usual September-October window. When it ships, new Layerbase databases will get the stable release, and the beta version disappears from the picker. Because beta data directories aren't guaranteed to carry forward, plan to recreate anything you built on the beta rather than upgrade it in place; for test workloads that's a pg_dump away, and for most of what a beta is for, it's nothing at all.

Create a PostgreSQL 19 Beta database and tell us what breaks. That's what betas are for, and bug reports filed now are worth ten filed in October.