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.
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
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
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.
stay tuned, there is a concerted effort to bring this area up to standards too.. more details will be discussed at the upcoming PGCon Ottawa and you will blogs on this subject in the latter half of the year
4 comments
[ 1.9 ms ] story [ 17.8 ms ] threadWhile 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.
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
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.