this is a follow up to a great discussion from last week - "The part of Postgres we hate the most: Multi-version concurrency control": https://news.ycombinator.com/item?id=35716963

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.

One of the more exciting projects in this space is OrioleDB[0] (disclosure: supabase is an investor/sponsor).

In Postgres 14 their patchset was ~5,000 lines of code (representing the total number of changes required in their fork). In the upcoming Postgres 16 release, it is ~2,000 lines of code. That means that around 60% of the code is already committed to the Postgres core.

We're hopeful that these changes can provide the possibility of several new storage implementations for postgres, much like the MySQL ecosystem have with their pluggable storage

[0] https://github.com/orioledb/orioledb