arenru
July 26, 2026#postgresql#sql#databases#backend#performanceavailable in Arabicavailable in Russian

PostgreSQL 19: Less Application Code, More SQL

PostgreSQL 19 Beta 2 landed July 16, 2026: single-trip upsert reads, read-your-writes on replicas, and standard temporal updates — less app code.

PostgreSQL 19: Less Application Code, More SQL

PostgreSQL 19 Beta 2 shipped on July 16, 2026, following Beta 1 on June 4, with general availability expected between September and October. What stands out is not the feature list — it is the direction. Work that has lived in the application layer for years is moving back where it belongs: inside the engine.

The problem: the compensation layer

Every team that has shipped a serious product carries code written to paper over gaps in SQL itself:

  • The double upsert. Insert a row, hit a conflict, then run a second SELECT to fetch the row that already exists. Two round trips, with a race window between them.
  • Replica lag. Write to the primary, read from a replica, and the user sees stale data immediately after saving. The usual workaround is routing reads to the primary for a while, or sticky sessions — patches, not solutions.
  • Temporal history. Update a price for one specific window only, and you end up hand-building history tables and writing period-splitting logic yourself.

Each of these works. Each is also extra code that needs tests and maintenance, and every line is a place a bug can live.

What changed in 19

Reading an upsert result without a second trip. INSERT ... ON CONFLICT DO SELECT ... RETURNING returns the conflicting row instead of returning nothing and forcing another query.

Read-your-writes on replicas. The new WAIT FOR LSN command makes a replica wait until it has caught up to a specific point in the write-ahead log before running the query.

Standard temporal updates. The FOR PORTION OF clause is now supported in UPDATE and DELETE, complementing the temporal constraints introduced in PostgreSQL 18.

Beyond those: GROUP BY ALL, ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS, a new REPACK ... CONCURRENTLY command, parallel autovacuum workers, up to 2x better insert performance with foreign key checks, and SQL/PGQ property graph queries.

A practical example

sql
-- Before: two round trips plus a race window
INSERT INTO customers (email, name)
VALUES ('sara@example.com', 'Sara')
ON CONFLICT (email) DO NOTHING
RETURNING id;
-- Empty result means you now need a second query

-- In 19: one trip, and the existing row comes back
INSERT INTO customers (email, name)
VALUES ('sara@example.com', 'Sara')
ON CONFLICT (email) DO SELECT
RETURNING id, email, created_at;

Reading immediately after a write:

sql
-- On the primary, right after the write
SELECT pg_current_wal_insert_lsn();   -- '0/3A1F0C8'

-- On the replica, before the query
WAIT FOR LSN '0/3A1F0C8';
SELECT id, total FROM orders WHERE customer_id = 42;

Updating one time window only:

sql
UPDATE prices
FOR PORTION OF valid_period
  FROM DATE '2026-08-01' TO DATE '2026-09-01'
SET amount = amount * 0.9
WHERE sku = 'ABC-123';

Real-world caveats

  • Beta means beta. Do not run it in production. The right use of this phase is a copy of your data, your real queries, and a report for anything that behaves oddly.
  • `WAIT FOR LSN` is not magic. The LSN has to travel from the writer to the reader through request context — a header or a cookie — and you need a timeout plus a fallback to the primary.
  • JIT is now disabled by default. Heavy analytical queries that relied on it need an explicit opt-in and a before/after measurement.
  • Security defaults moved too. RADIUS authentication was removed, and successful md5 authentication now emits warnings. Review pg_hba.conf before upgrading.
  • `default_toast_compression` now defaults to `lz4`.
  • A major upgrade is a project, not a command. It needs pg_upgrade or pg_dump/pg_restore, and it belongs on the calendar — the same shift toward scheduled, plannable updates seen in the Next.js security release program.

Takeaway

The direction in PostgreSQL 19 matters more than any single feature: the more data-correctness logic moves from the application into the engine, the less surface area a bug has to live in. The time to read the release notes and run the beta against a copy of your data is now — before the stable release arrives in the autumn.

Primary source: the PostgreSQL 19 Beta 2 announcement and the Beta 1 announcement from the PostgreSQL project.