Lessons Learned Extending Postgres: The Good, the Bad, and the Ugly

Postgres is the most extensible production-grade database. But extensibility has limits. Some changes require rewriting the core.

In this session, I will share lessons from 26+ years of extending and rewriting Postgres at scale. This work spans compatibility aspects, including behavioral semantics, wire protocols and modern APIs, SQL dialects and procedural languages, and direct access to Oracle and InnoDB data files. And it extends to federated query and data virtualization, as well as to core architectural changes such as alternative buffer pool implementations, multiple background writers, and AIO/DIO.

I’ll also cover the most painful aspect: MVCC. Vacuum and transaction ID wraparound are not flaws. They are consequences of Postgres’s architecture. Having implemented Oracle and InnoDB-style MVCC in Postgres, I will explain what it takes to rewrite visibility and cleanup semantics at the engine level, eliminate those consequences entirely, and what that changes about performance.

This is a candid look at what breaks, what bends, and what Postgres reveals when pushed far beyond its intended boundaries. We will close with what Postgres can learn from other engines, what they can learn from Postgres, and why Postgres remains one of the most important database architectures ever built.