FOSDEM 2026 — Defining "Drop-in Replacement" and Beyond

Obligatory photo from FOSDEM 2026. Credit: Marcelo Altmann

Back from Brussels where I was doing the annual pilgrimage to the awesome FOSDEM gathering. I was very pleased to see the popularity and positive vibe of the (first time) joint Databases Devroom. Community-oriented and community-run conferences are the best IMHO.

It was great to share the stage this time with Daniël van Eeden, an engineer from PingCAP and a MySQL Rockstar. I enjoyed the collaboration because we approached a thorny issue from two different aspects: the PostgreSQL emerging standard and the implementation of MySQL compatibility.

The Talk: "Drop-in Replacement"

Our presentation, "Drop-in Replacement: Defining Compatibility for Postgres and MySQL Derivatives", tackled a problem in our industry: the "wild west" of marketing claims. The success of open source databases has created an ecosystem of derivatives claiming "drop-in compatibility."

The reality, however, is that this often leads to user confusion and brand dilution. As we discussed, compatibility is not an absolute Yes/No situation—even different versions of the same database are not 100% compatible due to deprecated or added features.

The Standard: The Riga Consensus

In my section of the talk, I focused on the governance perspective. I presented the findings from the "Establishing the PostgreSQL Standard" working group held at PGConf.EU 2025 in Riga last October.

We are pivoting from a binary "Pass/Fail" certification to a granular compatibility matrix. We need to ensure that when someone says "Postgres Compatible," they don't just mean matching the wire protocol. We need to look at:

  • Core SQL & Implicit Behaviours: It's not just about functions; it's about undocumented behaviors users rely on, like how INSERT ... SELECT ... ORDER BY behaves.
  • System Catalogs: Monitoring tools rely on the pg_catalog being present and predictable.
  • No Silent Failures: A command like CREATE INDEX must actually build the index, not just return "success" while doing nothing.

The Implementation: The TiDB Experience

Daniël provided a very interesting look at the other side of the coin: the engineering reality of maintaining compatibility in TiDB, a distributed database written in Go.

He highlighted the "architectural friction" involved in making a distributed engine speak MySQL. For example, TiDB accepts the ENGINE=InnoDB syntax to remain compatible, but silently ignores it because it uses TiKV (RocksDB) for storage. He also showed how "Explain" formats can diverge significantly because distributed query plans simply look different than local MySQL plans.

Watch the Talk

We had a great turnout and some excellent engagement from audience members after the talk. If you missed it, you can watch the recording below:

Next Stop: Vancouver 🇨🇦

The conversation doesn't stop here. I am very excited to announce that we are taking this work to the next level at PGConf.dev 2026 in Vancouver!

Our session, "Establishing the PostgreSQL standard: What's Postgres compatible?", has been confirmed for the Community Open Discussion track.

As PostgreSQL becomes "the new Linux" for the enterprise, defining compatibility is critical. Building upon the foundations already set in Riga and Brussels, we will be continuing work on the granular compatibility matrix and test harness.

If you are going to be in Vancouver, please join us! We aim to leave the session with refined criteria, progress reports, and next steps for continued collaboration.

Check out current goings-on at the PostgreSQL Wiki: Establishing the PostgreSQL standard — What is Postgres compatible.