←back to thread

MVCC – the part of PostgreSQL we hate the most (2023)

(www.cs.cmu.edu)
366 points virtualwhys | 3 comments | 20 Oct 24 15:30 UTC | HN request time: 0s | source
Show context
hlandau ◴[20 Oct 24 17:06 UTC] No.41896827[source]▶
With every new PostgreSQL release we see yet more features and sugar added to the frontend, yet seemingly no meaningful improvement to the backend/storage layer which suffers these fundamental problems.

I wish the PostgreSQL community would stop chasing more frontend features and spend a concerted few years completely renovating their storage layer. The effort in each release seems massively and disproportionately skewed towards frontend improvements without the will to address these fundamental issues.

It's absurd that in 2024, "the world's most advanced open source database" doesn't have a method of doing upgrades between major versions that doesn't involve taking the database down.

Yes, logical replication exists, but it still doesn't do DDL, so it has big caveats attached.

replies(6): >>41896999 #>>41897049 #>>41897077 #>>41897182 #>>41905260 #>>41907744 #
1. jandrewrogers ◴[20 Oct 24 17:41 UTC] No.41897077[source]▶
The design of good storage layers in databases is deeply architectural. As a consequence, it is essentially a "forever" design decision. Fundamentally changing the storage architecture will alter the set of tradeoffs being made such that it will break the assumptions of existing user applications, which is generally considered a Very Bad Thing. The existing architecture, with all its quirks and behaviors, is part of the public API (see also: Hyrum's Law).

In practice, the only way to change the fundamental architecture of a database is to write a new one, with everything that entails.

replies(1): >>41901775 #
2. Negitivefrags ◴[21 Oct 24 08:05 UTC] No.41901775[source]▶
You could select which storage approach on a per table level. That way the new characteristics don’t surprise anyone.
replies(1): >>41902154 #
3. emptiestplace ◴[21 Oct 24 09:14 UTC] No.41902154[source]▶
This is the MySQL approach, but it isn't without downsides - consistency, predictability, etc.