Next steps for Postgres pluggable storage

I like Postgres. I've used it in production in the past as a default choice. I want to like Postgres. But I find my enthusiasm for using Postgres again in the future severely dampened by just how bad Postgres's replication story is.

Currently, Postgres has two options for replication:

- Physical replication, which is not binary-compatible between major versions, meaning that upgrading your database requires downtime

- Logical replication, which doesn't replicate DDL (let alone atomic DDL)

This is frankly silly. It seems like PostgreSQL's storage layer hasn't been improved much over the years and is now becoming quite an issue. It's actually surprising to me, since the binary compatibility break with every major version you would think would give them exactly the opportunity they need to make improvements here.

This isn't even to go into other issues like the XID wraparound issue, etc. It's time the world's most advanced open source database had a decent storage layer.

While Postgres MVCC isn't great compared to other engines, there are legitimate steps forward to solve this in Postgres core. In previous releases there was an implementation for ZHeap, and there are now ongoing efforts to introduce a better Table Access Method API which would enable other storage formats.

With some luck, most of this will be in PG17.