Establishing the PostgreSQL Standard: PGConf.dev 2026 Part Two

Again, apologies for the delay. PGConf.dev was back in May, and it has taken me until November to follow up on Part One.

This part is about "Establishing the PostgreSQL standard: What's Postgres compatible?", the session I ran with Hettie Dombrovskaya on the Tuesday afternoon in Vancouver, in the Community Discussion track of PGConf.dev 2026.

It follows on from the working session Hettie, Boriss Mejías and I organised at PGConf.EU 2025 in Riga, and from the talk at FOSDEM in February where Daniël van Eeden and I looked at the question from the Postgres and MySQL sides.

What came out of Riga is written up on the PostgreSQL wiki as the Riga Consensus, so I won't go over it again here, except to say that it moved us from a single pass/fail certification to a granular matrix of tests.

Introducing postgres-compat

A discussion about testing compatibility gets further when there is something concrete to test with, so shortly before the session I published postgres-compat, a reference implementation of the Riga framework, and our slides walked through the decisions it makes.

It runs three test engines and writes one report. For most of the SQL language it writes no tests of its own, and instead runs PostgreSQL's own pg_regress and pg_isolation_regress suites verbatim against the target, 200 regression tests and 117 isolation specs, comparing the output byte for byte.

YAML probes cover what the upstream suites can't express against an arbitrary server, such as silent failures, runtime configuration and the behaviour of contrib extensions. The directory tree of the probes is the taxonomy itself, with one file per topic under each of the three Riga domains.

The decisions we put up for discussion were these:

• Every test is either Core or Optional. Only a Core failure fails the run, and a skipped test doesn't count as a failure.
• The "feature compliance, not bug-for-bug" rule is narrow. A derivative doesn't have to reproduce an upstream bug, but it does have to match the upstream regression output.
• Silent failures count as failures. A statement that returns success without taking effect fails the test.
• It has to work on managed services. The harness never creates or drops a database on the target, and a refused permission is reported separately from a missing feature.
• Vendors publish their own reports. Anyone can reproduce a vendor's report.yaml, and the community can verify a claim but does not act as the gatekeeper.

📊 View the slides: Establishing the PostgreSQL standard: What's Postgres compatible? (PDF)

Where we are now, and what's coming

The repository is public under the PostgreSQL Licence and supports PostgreSQL 14 to 18. Next to the two upstream suites it has 74 YAML probes, 55 of them Core and 19 Optional, and a run exits non-zero if any Core test fails.

There is no release as of yet. The harness also connects to a single target, so the parts of the Riga Consensus that need a second node, such as bi-directional logical replication or a cluster that mixes vanilla and vendor nodes, are not covered, and neither is compatibility with tools like Patroni and repmgr.

In the hallway track we also talked with some of the maintainers of Postgres drivers for different programming languages about including their regression tests, because the drivers are a key part of compatibility too. Stay tuned for that.

This isn't abandoned, but I've put all of it on the back burner for now, and I promise you it's for a good reason: you should expect from me very soon a rundown of everything I was involved in at PGConf.EU 2026 in Valencia, and two other very exciting blog posts!

Many thanks to Hettie for running the session with me, and to everyone who came along and joined the discussion. If you would like to join it from wherever you are, find us on the PostgreSQL Compatibility Work Group Discord at discord [dot] gg [slash] x95WEyT6dc.