Published: 2026-07-09 • Updated: 2026-07-15

What's New in PostgreSQL 19 — and How a GUI Supports It

PostgreSQL 19 reached its first beta — beta 1 — in June 2026, and general availability is expected later in the year, following the project's usual annual cadence. Beta 1 is a testing release: run it on non-production systems and read the official release notes before you rely on anything new. This post walks the changes a database developer actually touches — SQL/PGQ property graphs, REPACK, partition MERGE/SPLIT, jsonpath string methods, autovacuum scoring, and new observability views — and shows where Jam SQL Studio already surfaces each one (as of version 1.4.15). Every product claim below maps to a shipped feature; PostgreSQL 19 itself is described as beta throughout.

The short version

PostgreSQL 19 (beta) lands a mix of headline SQL features and quieter operational plumbing. Here's the map of what changed and where Jam SQL Studio meets it:

Jam SQL Studio is a cross-platform desktop client (Mac, Windows, Linux) for SQL Server, PostgreSQL, MySQL, Oracle, and SQLite. It connects to a PostgreSQL 19 beta server exactly like any other PostgreSQL server and lights up the surfaces below — some gated on the detected server version, some offered on every PostgreSQL connection with the 19+ requirement noted in the generated script. On older servers everything degrades cleanly — hidden surfaces, informational notes, or automatic fallbacks, never an error.

SQL/PGQ property graphs: the headliner

The marquee SQL feature is SQL/PGQ — the ISO SQL property-graph extension. You define a property graph over existing tables (vertices and edges mapped to rows and foreign keys) and then query it with the new GRAPH_TABLE construct and a visual pattern language, instead of hand-writing recursive CTEs. See the PostgreSQL 19 release notes for the full grammar.

Jam SQL Studio already treats property graphs as first-class schema objects. When you connect to a server that exposes them, the Object Explorer grows a Property Graphs folder alongside Tables and Views. Each graph gets:

• CREATE and DROP scripting — Script as CREATE reads the server's own definition so you get the exact object back, and Script as DROP writes the teardown statement.
• A GRAPH_TABLE query template — a starter query that opens in the editor pre-filled against the selected graph, so you don't have to remember the pattern syntax from scratch.

Because Jam authors the GRAPH_TABLE skeleton for you and round-trips the graph definition through the server, the property-graph workflow doesn't depend on you memorizing beta-era syntax. Details are in the Scripting guide — and for a deeper dive into the syntax itself, including a live-tested comparison of what Oracle's and PostgreSQL 19's PGQ dialects each accept, see SQL/PGQ in Practice.

REPACK: bloat cleanup without the VACUUM FULL lock trade-off

PostgreSQL 19 adds REPACK, a built-in command that rewrites a table to reclaim bloat — the job people previously reached for VACUUM FULL or CLUSTER (or the external pg_repack extension) to do. The plain form takes an ACCESS EXCLUSIVE lock like VACUUM FULL; the parenthesized CONCURRENTLY option trades that for a rewrite that lets reads and writes continue:

-- PostgreSQL 19 (beta)
REPACK orders;
REPACK (CONCURRENTLY) orders;

Note the shape: CONCURRENTLY is a parenthesized option, not a bare trailing keyword. Jam SQL Studio surfaces this through the Maintenance submenu on a table's right-click menu in the Object Explorer, next to VACUUM and ANALYZE. The items are always present on PostgreSQL connections; picking one opens the generated script in a query tab so you can review it before running. When your server is older than 19 (or the version can't be determined), the generated REPACK script carries a note that REPACK requires PostgreSQL 19+ — the script is never silently emitted against a server that would reject it. See Scripting.

Server-native DDL: let PostgreSQL write the CREATE statement

Two new catalog functions let the server author DDL for objects that historically had no clean pg_dump-free way to script: pg_get_role_ddl(regrole) and pg_get_database_ddl(regdatabase). Both return SETOF text — one or more statements you concatenate:

-- PostgreSQL 19 (beta)
SELECT pg_get_role_ddl('demo');
-- CREATE ROLE demo SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION BYPASSRLS;

SELECT pg_get_database_ddl('dvdrental');
-- CREATE DATABASE dvdrental WITH TEMPLATE = template0 ENCODING = 'UTF8'
--   LOCALE_PROVIDER = libc LOCALE = 'en_US.utf8';
-- ALTER DATABASE dvdrental OWNER TO demo;

On a PostgreSQL 19 connection, Script as CREATE for a role or a database uses these server-authored definitions — so the DDL you copy is exactly what the server itself would emit, aggregated across every row the function returns. On servers below 19 the same menu falls back to Jam's hand-built generators, so the behavior you already know is unchanged. See Scripting.

jsonpath string methods: case-insensitive JSON matching

PostgreSQL 19's SQL/JSON path language gains string methods, including .lower(), so you can compare JSON scalars without caring about case:

-- PostgreSQL 19 (beta)
SELECT jsonb_path_exists('{"a":"ABC"}'::jsonb, '$.a ? (@.lower() == "abc")');
-- t

SELECT jsonb_path_exists('{"arr":[{"sku":"AbC"}]}'::jsonb,
                         '$.arr[*].sku ? (@.lower() == "abc")');
-- t

Jam SQL Studio's JSON filter chips gain matching case-insensitive operators for equality and array-any matching. Because .lower() is only valid on PostgreSQL 19, these operators appear in the filter dropdown only when the connection's server is 19 or newer — and they fail closed: if the version can't be determined, they stay hidden, even under "show all operators."

One honest limitation to know about: the value you type is lowercased in the app with JavaScript's toLowerCase() while the server compares with jsonpath .lower(). For ASCII these agree; for locale-special casing (Turkish dotted İ, German ß) they can disagree, which can miss matches on non-ASCII values. The JSON Columns guide documents this and the rest of the JSON filter stack.

Autovacuum scoring: see what vacuum is about to do

PostgreSQL 19 continues to sharpen autovacuum — and it exposes the planner's own thinking through a new view, pg_stat_autovacuum_scores, which ranks every table by how urgently it needs vacuuming or analyzing:

-- PostgreSQL 19 (beta)
SELECT relname, score, vacuum_score, analyze_score, do_vacuum, do_analyze
FROM pg_stat_autovacuum_scores
ORDER BY score DESC;

Jam SQL Studio adds an Autovacuum panel to the Performance Dashboard (Instance Monitor) that reads this view on PostgreSQL 19, so you can see at a glance which tables autovacuum is prioritizing. On servers below 19 the panel shows a "requires PostgreSQL 19+" info card rather than failing — the same graceful-empty pattern the rest of the dashboard uses. See the Performance Dashboard guide. (PostgreSQL 19 also brings broader autovacuum improvements; the release notes have the full list.)

Partition management: MERGE and SPLIT in one statement

Declarative partitioning gets two long-requested operations. ALTER TABLE ... MERGE PARTITIONS folds several partitions into one, and ALTER TABLE ... SPLIT PARTITION divides one partition into several with fresh bounds:

-- PostgreSQL 19 (beta)
ALTER TABLE measurements
  MERGE PARTITIONS (measurements_a, measurements_b) INTO measurements_ab;

ALTER TABLE measurements
  SPLIT PARTITION measurements_ab INTO (
    PARTITION measurements_a2 FOR VALUES FROM (0) TO (100),
    PARTITION measurements_b2 FOR VALUES FROM (100) TO (200)
  );

Jam SQL Studio improves partitioned-table handling in two ways. First, declaratively-partitioned parents now appear in the Tables folder with a dedicated Partitions subfolder that lists each child partition with its FOR VALUES bound inline — and partition children no longer clutter the top level as standalone tables. That listing works on PostgreSQL 10 and later, not just 19. Second, the partition context menus generate the reshaping scripts: Script SPLIT PARTITION on a partition node and Script MERGE PARTITIONS on the Partitions folder. Those two scripts are PostgreSQL 19-only, so — like the Maintenance menu — the generated SQL carries a version note when the server is older. Every generated statement uses schema-qualified, quoted identifiers. See Scripting.

Observability: lock statistics and EXPLAIN IO

Two new observability surfaces are worth wiring into a client. pg_stat_lock is a cumulative view with one row per lock type, tracking how often waits happened and how long they took:

-- PostgreSQL 19 (beta)
SELECT locktype, waits, wait_time, fastpath_exceeded, stats_reset
FROM pg_stat_lock
ORDER BY waits DESC;

Jam SQL Studio adds a cumulative Lock Statistics section to the Locks tab of the Session Browser that reads this view. On PostgreSQL 18 and earlier the section is simply absent — not an error.

The second is a new IO option for EXPLAIN, which reports per-node I/O and prefetch statistics. It requires ANALYZE:

-- PostgreSQL 19 (beta)
EXPLAIN (ANALYZE, BUFFERS, IO, FORMAT JSON) SELECT count(*) FROM actor;
-- scan nodes gain "I/O Count", "I/O Waits", "Average I/O Size",
-- and prefetch-distance keys

When you capture an actual execution plan on PostgreSQL 19, Jam SQL Studio includes the IO option and the plan viewer surfaces the resulting I/O properties on each node (plus Execution Time in the summary). On PostgreSQL 16 the plan output is unchanged — no IO option is emitted, so nothing breaks.

Smaller syntax wins, ready as snippets

PostgreSQL 19 (beta) also lands a batch of smaller SQL conveniences. Jam SQL Studio ships them as built-in snippets so they're a few keystrokes away in the editor:

-- ON CONFLICT DO SELECT: read the conflicting row instead of erroring
INSERT INTO tags VALUES (1, 'b') ON CONFLICT (id) DO SELECT RETURNING *;

-- FOR PORTION OF: update or delete only part of a temporal row's validity range
UPDATE prices FOR PORTION OF valid_at FROM '2026-06-01' TO '2026-09-01'
  SET price = 12;
DELETE FROM prices FOR PORTION OF valid_at FROM '2026-06-01' TO '2026-09-01';

-- GROUP BY ALL: group by every non-aggregated column
SELECT relkind, count(*) FROM pg_class GROUP BY ALL LIMIT 5;

-- WAIT FOR: block until WAL reaches a target LSN
WAIT FOR LSN '0/036C6B78' WITH (MODE 'primary_flush', TIMEOUT '1000');

The temporal FOR PORTION OF syntax also fixes a real editor papercut: Jam's destructive-statement guard — the confirmation prompt that catches an unqualified UPDATE or DELETE — now understands FOR PORTION OF, so a scoped temporal update no longer trips a false "this looks dangerous" warning.

Trying it out

PostgreSQL 19 is beta software: pin it to a scratch server, keep backups, and treat every feature above as subject to change until GA. If you already run Jam SQL Studio, point a connection at a PostgreSQL 19 beta instance and the version-gated surfaces light up automatically — and everything degrades cleanly back to the PostgreSQL 16 experience on older servers. The full list of what shipped in this release is on the changelog.

FAQ

Is PostgreSQL 19 stable enough for production?

Not yet. PostgreSQL 19 is in beta as of beta 1 (June 2026); beta releases are for testing and are not covered by the project's usual stability guarantees. General availability typically follows later in the year, on PostgreSQL's usual annual cadence. Test PostgreSQL 19 on non-production systems, and read the official release notes before relying on any new feature.

Does Jam SQL Studio work with PostgreSQL 19 beta?

Yes. Jam SQL Studio connects to a PostgreSQL 19 beta server the same way it connects to any PostgreSQL server, and all the PostgreSQL 19 surfaces light up there: REPACK maintenance scripts, server-native role and database DDL, case-insensitive jsonpath filters, the autovacuum-scores panel, partition MERGE/SPLIT scripts, cumulative lock statistics, and EXPLAIN IO statistics. The handling varies by surface — panels, statistics sections, and filter operators are gated on the detected server version, the REPACK and partition MERGE/SPLIT script generators are always offered and note the PostgreSQL 19 requirement in the generated SQL, and role/database scripting tries the server's native DDL functions first and falls back automatically. Everything else behaves exactly as it does on earlier PostgreSQL versions.

Do these PostgreSQL 19 features work on PostgreSQL 16?

The server-side features are PostgreSQL 19-only, so Jam SQL Studio gates each surface on the connection's server version. On PostgreSQL 16 (or any version below 19) the version-only surfaces are hidden or replaced with an informational note rather than an error: the jsonpath case-insensitive operators disappear, the autovacuum panel shows a 'requires PostgreSQL 19+' card, the lock-statistics section is absent, EXPLAIN runs without the IO option, and Script as CREATE falls back to Jam's own DDL generators. Reading partitioned tables in the Object Explorer works on PostgreSQL 10 and later; only the partition MERGE and SPLIT scripts are PostgreSQL 19-only.

Which PostgreSQL 19 features does Jam SQL Studio support today?

SQL/PGQ property graphs (a Property Graphs folder in the Object Explorer with CREATE and DROP scripting and GRAPH_TABLE query templates), REPACK through the table Maintenance menu, server-native pg_get_role_ddl and pg_get_database_ddl for Script as CREATE, case-insensitive jsonpath filter operators, an autovacuum-scores panel, partition MERGE and SPLIT scripts, cumulative lock statistics from pg_stat_lock in the Session Browser, EXPLAIN IO statistics in the plan viewer, and built-in snippets for new syntax such as ON CONFLICT DO SELECT, FOR PORTION OF, GROUP BY ALL, and WAIT FOR.