Neki – Sharded Postgres by the team behind Vitess

By MVCC you mean the kind of MVCC that keeps old versions in the same space / requires vacuum? Because I'm pretty sure Oracle also does multiversioning using their undo log / rollback segment.

You forgot the read the original text above my response.

> I looked Neon recently, and it appears that it's designed as a SaaS product from the outset; while it is technically possible to self-host the individual components of the architecture, it does not look trivial, in large part because the control plane is closed source (and probably extremely specific to Neon's SaaS operations).

This is a good reason to go with multigres vs Neki (assuming Neki gets integrated into planetscale vs a standalone multigres ).

The two announcement's regarding Neki smells like its going to be proprietary or heavily tied into planetscale. See the gauging interest two months ago with sign ups. The current signing up ... Feel very marketing focused.

https://planetscale.com/blog/planetscale-for-postgres#nova-v...

> If your company runs Postgres at a significant scale and this is something that interests you, reach out.

> Sign up for the private preview of PlanetScale for Postgres waitlist here.

https://planetscale.com/blog/announcing-neki

> To stay up to date with the latest developments on Neki you can signup at neki.dev.

Where as the multigres via Supabase points to github repo's, the license, etc...

https://supabase.com/blog/multigres-vitess-for-postgres

> Like Vitess, Multigres will be open source using the same license: Apache 2. You can follow the repo here.

We shall see, but one is running and acting like pure open source project, and another is being announced how the marketing department of a proprietary software company works.

And the timing is interesting. Coincidence that both Neki and multigres got announced right at the same time? I am suspecting there has been some background drama going on with planetscale and supabase. But that is off-topic.

Like i said, and i agree with the poster i responded too: That Neki smells like its going to be tied into planetscale.

Calling undo/redo MVCC isn't really accurate. The whole point of Postgres' style of MVCC is that updates leave the original rows unmodified, which allows concurrent transactions to read them without extensive locking or redirection.

In Oracle's database engine, when transaction A updates a row, it begins by reading the old row, updating it in-place, and adding the old row to the undo log. The heap row has a header with a list of transactions currently accessing that row and pointers into the undo log. If a transaction B comes in (while A is still ongoing) and wants to read the row, it startsby reading the current row header, where it sees that someone else has modified it, and then goes to the undo log to read the old version. (This is all very simplified.)

The huge benefit of the undo log is that the main heap doesn't get bloated with old data. Deletes cause holes, of course, but updates do not. Meanwhile, the undo log can be trivially be truncated when rows are no longer needed. Postgres, since it effectively mixes undo data with current versions, needs to do vacuuming. Postgres may win when there's a huge amount of contention around hot spots, but arguably loses when it comes to "normal" transactional volume.

OrioleDB adopts Oracle-style undo logging, among other table layout improvements, and their own OLTP benchmarks show extreme performance improvement over mainline Postgres.

Discussed on The Changelog podcast: https://changelog.com/podcast/651

YugabyteDB is also a fork of PostgreSQL. Last year, they got around to rebasing from 11 to 15, and spent some time working on better isolating their changes to make that easier going forward.

https://www.yugabyte.com/blog/yugabytedb-moves-beyond-postgr...

> When we set out to make YugabyteDB Postgres-compatible, we took a fork of Postgres, and modified all of the operations that use shared memory or storage to instead talk to our LSM- and Raft-based distributed storage and transaction layer.