Latest Blog Posts

In distributed database environments, balancing durability and performance is a constant tug-of-war. PostgreSQL’s synchronous_commit parameter sits at the heart of this, giving administrators a dial to choose exactly when a COMMIT returns success to the client.

The idea of remote_receive was born from a simple question: does skipping the standby's disk write yield a measurable, real-world performance benefit? By waiting only for WAL bytes to reach the standby's memory, could we get a meaningful boost over remote_write? I set out to implement and benchmark this feature to find out.

What followed was a journey through network latency, OS page caches, CPU scheduler thrashing, and benchmarking noise. Here is the breakdown of the implementation, the tests, the initial anomalies, and the final results.

1. The Feature: What is remote_receive?

Before this branch, PostgreSQL offered four primary synchronous commit modes:

• off: Fully asynchronous. (Fastest, least safe)
• local: Waits for local disk flush on the primary.
• remote_write: Waits for the standby to write the WAL to its OS buffer cache (pwrite).
• remote_apply: Waits for the standby to fully replay the WAL. (Slowest, most safe)

remote_receive sits directly between local and remote_write. In this mode, the primary guarantees that the WAL bytes have physically arrived at the standby's walreceiver process buffer. It does not wait for the standby to call pwrite().

The Hypothesis: By completely bypassing the standby's disk I/O, remote_receive should deliver lower latency and higher throughput than remote_write, especially on replica hardware with slow disks.

Implementation Details

To build this, I had to modify both the standby and the primary:

1. Standby Status Update: I modified the 34-byte wire message that the standby sends to the primary, adding a new 8-byte receivePtr (creating a 42-byte message, backward compatible).
2. Early Replies: I modified walreceiver.c to send a reply me

The Landscape Has Changed

When I was at Turnitin, we were still kind of riding the tail end of the dot-com boom. People were rushing to ship things, and brief outages were not exactly good, but they were considered a normal part of running software on the internet. If the site was down for a few minutes, you’d shrug, dig in, and fix it.

That’s not really the world we live in anymore. Uptime is much more sensitive than it used to be. Five nines used to be the stretch goal – now four nines is something a lot of teams just treat as the expectation, and even a few minutes of outage in a month feels like a lot. We don’t really track averages in our metrics anymore, either; we track p99 latencies, because we actually care about that last 1% of users having a good experience.

The other thing that’s changed is how quickly outages get socialized. A noticeable hiccup in your service can end up on social media before your on-call has even finished acknowledging the page. In my experience, the worst situations are the ones where customers find out about an issue before the company does. That has both a financial cost and a reputational cost, and the reputational cost tends to linger long after the incident is resolved. Frequent outages chip away at users’ willingness to keep using your product.

Postgres is, of course, no exception. So that’s the world a Postgres DR plan has to operate in.

What Counts as a Disaster?

When people hear “disaster recovery,” I think the natural mental picture is a natural disaster – a flood, an earthquake, a wildfire, or maybe a long utility outage that takes a data center offline. And those are real concerns; we put generators and solar panels and multi-region replication in place partly to deal with exactly that.

But in my experience, most of the disasters that take a Postgres database down don’t look anything like that. They look like:

• A performance regression after a failover, where the service is technically “up” but slow enough that customers can’t really u

A NOT IN query can return the wrong answer without telling you. It is valid SQL, it runs without an error, and it hands back a perfectly well-formed result set that happens to be empty when it should not be. No warning, no hint, nothing in the logs: just zero rows where you expected hundreds, and a database that considers it correct.

Almost always the cause is a single NULL sitting somewhere you forgot to look, combined with two keywords you have typed a thousand times: NOT IN. None of it is a Postgres bug. This is exactly what the SQL standard mandates, implemented faithfully. That is precisely what makes it so easy to walk into, and why the planner could not safely optimize around it for about twenty-five years. It comes down to one if statement in the parser.

Sample schema

Nothing elaborate. A table of products, one of which has no category assigned yet, and a table of archived categories that happens to contain a NULL:

CREATE TABLE products (id int, category_id int);
INSERT INTO products VALUES (1, 10), (2, 20), (3, NULL), (4, 10);

CREATE TABLE archived (category_id int);
INSERT INTO archived VALUES (20), (NULL);

The NULL in archived is not contrived. The moment a column is nullable (and most are, by default), a NULL can find its way into any subquery you point a NOT IN at. That is the whole point: this is not an exotic data condition, it is the ordinary one.

The query that returns nothing

Here is the request you have written a hundred times: give me the products whose category is not archived.

SELECT id, category_id FROM products
WHERE category_id NOT IN (SELECT category_id FROM archived);

You expect products 1 and 4 (category 10, which is not in the archived set). What comes back is:

 id | category_id
----+-------------
(0 rows)

Every row gone. Not a subset, not an off-by-one: all of them. Drop the NULL from archived and the same query behaves:

SELECT id, category_id FROM products
WHERE category_id NOT IN (SELECT category_id FROM archived
                          WHERE 

Recently, a new type of question has entered the database arena: what did this data look like last Tuesday? Maybe it's the price of a product before the holiday sale kicked in, or which department an employee belonged to before that reorg nobody asked for. Short of adding an entire audit trigger system, how can we know what data looked like before and after a change at that exact date?The SQL:2011 standard formalized a proper solution over a decade ago with temporal tables. Other database engines adopted pieces of it relatively quickly. Characteristically, Postgres took its time. But Postgres 19 is finally bringing native temporal table support to the party — and it's been well worth the wait.Let’s see what we’re working with.

The Old-Fashioned Way

• Everyone knows BTREE and indexing in general, but
• is specific to Postgres and thus requires experience to understand. This goes double for being an
• extension.

• The exclusion constraint syntax is quite non-intuitive. It’s in the documentation, but there’s no reason anyone would think of this as the standard approach otherwise.

• There’s no temporal awareness baked into the table itself.

A colleague asked me recently if there was an API for querying the PostgreSQL Buildfarm database. I told him there was not. I'm aware that a number of people have been scraping the web pages for data, so it seemed like there was a good case for something better. And with a little help from claude code, I create one. It's live now. There's a full description at https://github.com/PGBuildFarm/server-code/blob/main/API.md

I'm particularly interested to hear from people how this might be usefully extended.

Here's an example of use, getting the latest status for the member crake on the master branch

TL;DR: The pgEdge AI DBA Workbench is four services on a shared Postgres datastore: a collector, a server, an alerter, and a React client that renders the dashboards and the chat panel where Ellie lives. Ellie is an agentic loop that drives any LLM you choose (Claude, ChatGPT, Ollama, or anything OpenAI-compatible) through a fixed set of database-aware tool calls. The model never queries Postgres directly, which is rather the point. Anomaly detection runs three tiers: z-score baselines, pgvector similarity against historical patterns, and LLM escalation for the residual cases. Source on GitHub under the PostgreSQL Licence.Most developers I talk to have a similar reaction when somebody tells them an LLM is going to manage their database: a polite nod, followed by a question about how the model is supposed to know the difference between a healthy snapshot on a quiet Tuesday and a runaway transaction on a Black Friday morning. It is a fair question, and it is the question we have been trying to answer whilst building the pgEdge AI DBA Workbench and its conversational interface, Ellie. You can run the Workbench as a pure monitoring platform with the AI switched off, and it is a perfectly capable one; but after months of working with Ellie enabled, none of us choose to.

Four Components and One Datastore

Introduction

PGDay Boston 2026 was a rewarding reminder of why I value the PostgreSQL community so much. It was delightful to reconnect with familiar faces, meet new people, and finally put some faces to names for the first time. One of the best parts of the day was the sense that this community is larger than any one employer or project. It is built on shared curiosity, shared responsibility, and a willingness to help one another learn. I’m honored to have been able to share my own thoughts in my Disaster Recovery talk as well.

The keynote, Michael Stonebraker’s “Where Did Postgres Come From?”, was a standout for me. I especially appreciated the history of Postgres and the years before Postgres, during the Ingres era. It was striking to hear how the project could have ended up as just another academic system, yet instead grew into something enduring because people outside of UC Berkeley took ownership of it and built a broader community around it. That story felt like a good reminder that open source succeeds not only through technical merit, but through stewardship and continuity.

I also enjoyed Brian Brennglass’s talk, “Managing and Observing Locks.” His demos made an intimidating topic much easier to follow, and I found the practical framing especially useful. Shree Vidhya Sampath’s session on leveraging Patroni’s synchronous replication while running PostgreSQL on Kubernetes was another highlight. I appreciated the clear discussion of election behavior, synchronous replication, and failover scenarios, including failure modes I had not experimented with myself.

Robert Haas’ “pg_plan_advice: Plan Stability and User Planner Control for PostgreSQL?” was impressive in his attention to detail, especially the way he tested edge cases that people might not think to check. Bruce Momjian’s “What’s Missing in Postgres?” was also thought-provoking because it framed missing features not as oversights, but often as deliberate choices shaped by the needs of the broader community. Ryan Booz’s “Mastering P

The Prague PosgreSQL User Group met on June 1, 2026, organized by Gülçin Yıldırım Jelínek and Mayur B.

Speaker:

• Laurenz Albe
• Josef Šimánek
• Ants Aasma

PGDay France 2026 took place from June 3-4

Organizers:

• Jean-Paul Argudo
• Jean-Christophe Arnu
• Sylvain Beorchia
• Damien Clochard
• Matt Cornillon
• Flavio Gurgel
• Yohann Martin
• Xavier Simon
• Anaïs Oberto

Talk selection Committee:

• Yves Colin
• Bertrand Drouvot
• Naeva Mallet
• Helene Nguyen

Speaker:

• Philippe Viegas
• Jean-Christophe Arnu
• Damien Clochard
• Matt Cornillon
• Julien Acroute
• Wilfried Roset
• Frédéric Delacourt
• Haritabh Gupta
• Luigi Nardi
• Franck Pachot
• Vincent Mercier

Lightning Talks:

• Cédric Duprez
• Etienne Bersac
• Thibaud Madelaine
• Sébastien Delobel
• Alain Lesage

PG DATA 2026 took place on June 4-5 2026.

Organizers:

• Carlos Aranibar
• Hettie Dombrovskaya
• Pat Wright
• Ellyne Phneah

Talk Selection Team:

• Dian Fay (non voting chair)
• Gülçin Yıldırım Jelínek
• Jay Miller
• Andrew Atkinson
• Derk van Veen

CoC Committee:

• Laetitia Avrot
• Umair Shahid
• Jimmy Angelakos

Trainings:

• Andrew Atkinson
• Lætitia Avrot
• Shaun Thomas

Speaker:

• Robert Haas
• Radim Marek
• Umair Shahid
• Sam Wilson
• Hajira Sultana
• Greg Potter
• Gleb Otochkin
• Nida Fatima
• Sami Imseih
• Chirag Dave
• Steve Zelaznik
• Henrietta Dombrovskaya
• Pavlo Golub
• Sukhpreet Kaur Bedi
• Nazneen Jafri
• Ryan Booz
• Denis Magda
• Jimmy Angelakos
• Paul Jungwirth
• Ellyne Phneah
• Apoorv Garg
• Shaun Thomas
• Kellyn Gorman
• Egor Tarasenko
• Devrim Gunduz
• Dian Fay
• Lukas Fittl
• Pat Wright
• Alfredo Rodriguez
• Naresh Reddy Regalla
• Varun Dhawan
• Wagner Bianchi

Lightning Talk Speaker:

• Anna Bailliekova
• Pavlo Golub
• Arushi Malhot

The old Postgres Conferences always sounded interesting, but the conference being in Ottawa in Canada and me being in Europe, I've always dismissed them as "too far away" and never bothered going.

Then the organizing team changed and the conference moved to Vancouver for 2024. That's even further away. 2025 in Montreal was a bit closer again, but…

At the October 2025 PGConf.EU conference in Riga, everyone was again excited about the upcoming PGConf.dev 2026 conference. Melanie Plageman, with her organizer hat on, told me "you should definitely come".

So, I finally signed up to join the legendary PostgreSQL developers conference. It was taking place in Vancouver again, and while I had ignored that another extra incentive in 2024, I have family living in Vancouver, so it would be nice to see my sister-in-law's family again.

Pavlo, Ants and I had coordinated travel so we would be on the same plane from Frankfurt to Vancouver. The conference started on Tuesday but we were already going on Sunday so we would have some time to accommodate before. The weird thing about flying west is that time isn't passing, we basically boarded at 10 am and nine hours "later" got off the plane at 10 am again, so we had a full Sunday to start exploring the town. But since we were tired, we were at the hotel at around 5 pm and I slept from 7 until 4 the next morning. Monday was spent going around Stanley Park on rented bikes, where we met the first other attendees.

Tuesday

Tuesday was the first conference day, filled with community discussion sessions. New to me, the conference had organized breakfast for all attendees, so everyone was coming in a bit earlier and we got the hallway track going. This is frankly the most interesting part of any conference to me, talking to old friends, meeting new faces and connecting then to names already known, and exchanging ideas about PostgreSQL and the world. After the opening, Devrim and I had a slot scheduled for making PostgreSQL ecosystem packaging (more) visible where

PostgeSQL 19 beta 1 has been released on 2026-06-04.

The release is planned for September 2026, though it’s time to go through the new features and changes.

My Top Three Features

All three features below are cool and great developments from the authors of the patches that implemented them. But there are a lot of new cool features and extesnions to exisiting features done by a lot of people.

My thanks go out to all the people who made PostgreSQL 19 possible.

For all others there is still the opportunity to be part of that people, your time is now to test the current and comming beta and release candidates of PostgreSQL 19. And please report bugs you may find.
That way you help all users having a stable release version ready to use in production.

INSERT

The INSERT became a new conflict action: It can now return a SELECT for conflicts.

Previously it already hat the options DO NOTHING and DO UPDATE, the first one did exactly what it was named, doing nothing, the second on offered to update the already existing columns.

The SELECT gives a complete new set of possibilities to handle existing data in an INSERT statement.

REPACK

Previously one needed an extension, pg_repack, but repack is now a command directly availabe in PostgeSQL 19.

Not only is it now a command, it also supports the parameter CONCURRENTLY. That way repack does not affect current database sessions.

And you can pass an index name of an existing index to sort the repacked table after an index. When you have defined the sortorder with CLUSTER and you do not pass an index name, the sortorder is done after the index specified in CLUSTER.

That does obviously not solve the problem of having the table data always physically sorted, but at least with REPACK as regular maintenance job, the data is mostly sorted.

SQL/PGQ

Graph Query Language (GQL) is a standardized query language for property graphs.

SQL/PGQ is the SQL standard extension to add the Graph Query Language to relatianonal datab

Every PostgreSQL developer eventually reaches the same architectural boundary, although the boundary usually appears as an ordinary product request rather than a database design problem. An application transaction needs to complete one business operation, but the surrounding platform also needs to write an audit record, launch a slow report, refresh a cache, fire a notification, or start some enrichment logic that should not delay the user. The first version of the application usually places that extra work inside the same transaction because that approach is simple and convenient. The problem appears later, when a rollback removes diagnostic information, a slow report increases API latency, or a user request begins carrying the weight of every downstream process that the business has attached to it.

PostgreSQL is excellent at transactional consistency because it ensures that related changes succeed or fail together. That behavior is exactly what you want when an order, payment, inventory adjustment, or account update must remain correct. However, there are real-world cases where the triggering transaction and the follow-on work should not share the same fate. An audit record should survive a rollback, a notification should not hold an HTTP request open, and an analytical report should not force a user to watch a spinner while PostgreSQL scans millions of rows.

PostgreSQL does not provide Oracle-style autonomous transactions as a built-in feature, so teams often create their own patterns around this gap. Some teams use dblink loopbacks to force work through another database connection, while other teams use LISTEN and NOTIFY with external workers, polling tables, cron jobs, or message queues. These approaches can work, and larger platforms may still need full orchestration layers when the workflow spans many services. However, when the work is fundamentally SQL that should run inside PostgreSQL, the extra infrastructure can feel like a small bridge built to cross a puddle.

pg_background addres

1. pgsql_tweaks is a bundle of functions and views for PostgreSQL
2. Changes In The pgsql_tweaks 1.0.3 Release

pgsql_tweaks is a bundle of functions and views for PostgreSQL

The source code is available on Codeberg.

The extension is also available on PGXN.

The extension is also availabe through the PostgreSQL rpm packages.

Changes In The pgsql_tweaks 1.0.3 Release

This release has been tested against PostgeSQL 19 beta 1 which was released on June 4 2026.
All tests against this new have been successfully passed.

PostgreSQL 13 has been removed from the supported versions as it went out of support on November 13 2025.

In addition the schema description in the function get_markdown_doku_by_schema is now done with a COALESCE to avoid concatenation wiht a NULL value and returning NULL as a result.

The Postgres community values feedback from testing of Beta releases, and with Docker it’s been easier to get pre-release versions up and running.

With the recent announcement of PostgreSQL 19 Beta 1, let’s get that running and test some of the new capabilities.

Pre-Release Versions of Postgres with Docker

First, you’ll need to install Docker for your OS! Grab the version needed for your OS and processor architecture, for example ARM or AMD/Intel/x86.

On MacOS run uname -m or sw_vers in your Terminal to learn more about your hardware details.

For Windows check Install Docker Desktop on Windows

Building and Running

Official Postgres images for Docker Postgres are limited to fully released versions.

Fortunately @yosifkit created a PR to add 19 Beta 1 (merged by @tianon) with instructions for how to use docker buildx to build pre-release versions.

This command downloads and builds postgres:19beta1-trixie:

docker buildx build -t postgres:19beta1-trixie \
    'https://github.com/infosiftr/postgres.git#19-rc:19/trixie'

With that built, I could invoke docker run with postgres:19beta1-trixie. I named mine pg19.

I also passed the env vars below based on how I run other Docker Postgres containers (these options may not be necessary).

The final command:

docker run \
--name pg19 \
--env POSTGRES_USER=postgres \
--env POSTGRES_PASSWORD=postgres \
--detach postgres:19beta1-trixie

To check if it’s running, I run docker ps -a. For logs I’d run: docker logs -f postgres:19beta1-trixie.

Connect via psql

The container is running and the logs have what we want: “database system is ready to accept connections”.

Let’s connect to the postgres database using psql on the container:

docker container exec -it pg19 psql -U postgres

We should see output like showing version 19:

psql (19beta1 (Debian 19~beta1-1.pgdg13+1))
Type "help" for help.

New Feature Testing in 19

Great. Let’s try out some things in 19.

19 Added a new system view for che

I shared a chart, in 2022, showing where PostgreSQL contributor gifts are mailed to.  Here's an updated chart (click to zoom in.)

To quickly recap: the PostgreSQL community has been sending gifts to those who contribute directly to a new major release since version 12 came out.  There has now been 6 releases since then and version 19 is slated to be released this fall.

This chart can be construed as a gross indication of where code, testers, reviewers, bug reports, and documentation are coming from.  Thus it is interesting to see things like which countries have the most people, have been growing, or even to just see how many countries are involved with PostgreSQL.

But it's not an exact measure because this is based on the number of people who claim their gift.  Only about half the people in the release notes claim their gift.  It's not very easy to get in touch with everyone.  If you suspect you might be in the release notes or can help someone claim their gift, please take a look at the release notes (links can be found in the documentation or on the community wiki) and reach out to us by e-mail at contributor-gifts <at> postgresql.org to confirm.

Well, the world has officially ended. Peter Venkman from Ghostbusters was right all along, and we'll soon be experiencing "human sacrifice, dogs and cats living together, mass hysteria!" Pack it in everybody; we had a great run. The feature freeze of Postgres 19 includes the one feature many claimed would never see the light of day: query hints. I guess "never say never" is pretty good advice.OK, so they're not technically called hints. The Postgres community would never be so pedestrian. Instead, Postgres 19 introduces two new contrib modules: pg_plan_advice and pg_stash_advice. It's "plan advice" you see. Totally different thing.An occasion this monumental deserves a bit more fanfare than simply describing the feature. So let's begin with a walk through one of the longest-running arguments in Postgres history.

A Brief History of "Never"

• They create maintenance nightmares.

• They break on upgrades.

• They discourage root-cause analysis.

• They scale poorly.

• The optimizer is usually smarter than you think.

• They actually
• planner improvements because users stop reporting bugs.