This is exciting. The announcement says it will be open source. I really hope that this includes a functionally complete control plane so you realistically self-host.
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).
benjiro 12 hours ago [-]
Your probably better off with the original flavor (the guy that made Vitesse)
Multigres is made by the guy that made Vitess, Sugu, before it became a startup. Doesn't mean it will be better, but I think it's why people have high hopes for both products.
andrew_mason1 2 hours ago [-]
there are also a significant number of previous vitess maintainers that have gone to supabase to work on it with him, so there's that.
it is not at all accurate to say that neki is made by "the team that brought you vitess" and that multigres is somehow not
benjiro 3 hours ago [-]
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.
> 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.
shoeb00m 18 hours ago [-]
Looks like there is two ongoing vitess for postgres projects. Hopefully this competition leads to a better postgres ecosystem.
OrioleDB is not about sharding, it's about the storage layer.
qaq 16 hours ago [-]
I did not claim OrioleDB is about sharding. It was just an observation that Supabase is contributing to Postgres ecosystem through multiple projects.
selfhosttoday 16 hours ago [-]
they likely said that because the context is "vitess for postgres projects" and OrioleDB is not "vitess for postgres"
purpleidea 12 hours ago [-]
Maybe make the announcement after you've actually released code?
Today I'm announcing I've cured cancer. Well not yet, but coming soon hopefully!
tpetry 4 hours ago [-]
More like: We‘re announcing to work on a cure in cancer! Isn‘t that aweslme? No, we dont have anything yet. But we started working on it. ETA? When its done. We dont share roadmaps with outsiders.
Reubend 10 hours ago [-]
Very cool, and I'm looking forward to using this. But unfortunately it seems like it's not actually released yet?
I'm a little surprised to hear that PlanetScale is doing the work to make this considering I thought their entire system was based on Vitess. Maybe the demand for Postgres compatible DBs is so high nowadays that they need to offer compatibility for customers that don't want to port their apps to MySQL's syntax?
kyrra 13 hours ago [-]
They did a interview 2 weeks ago about this on the changelog podcast with Sugu Sougoumarane, the co-creator of Vitess, who is at Supabase now. Watching the competition year will be interesting
Does Neki still need sharding key in query, just like Citus?
rockwotj 13 hours ago [-]
If it’s like vitess then no, but IIRC you get relaxed consistency across shards
n_u 8 hours ago [-]
Regarding cross-shard consistency, there's a doc here[1] on the options. In short you can just send the writes to all replicas, you can disallow cross-replica transactions (read and write), use two-phase commit to perform a distributed transaction or use their own hybrid approach that they set as the default.
Who isn't? Cockroach rewrote Postgres in Go. CedarDB rewrote Postgres in C++.
And then to lesser degrees you've got Yugabyte, AlloyDB, and Aurora DSQL (and certainly more I'm forgetting) that only replace parts of Postgres.
gethly 7 hours ago [-]
> Feels like it might be very useful since a lot of new technologies came out since spinning disks.
The MVCC that Postgres uses(and no one else) is like 50yo outdated concept they still cling to. So just by virtue of that, it makes PGSQL the most archaic db on the market nowadays.
I never understood why PGSQL had so many fanboys, yet every major tech company always ditches it for mysql... i guess it is the case of "Any man who must say, "I am the King", is no true king." type of thing. People have to make a lot of noise to excuse their bad choices so they don't have to admit making a mistake.
erpellan 6 hours ago [-]
I can’t believe they still make processors out of sand. Talk about outdated technology.
Sarcasm aside, a great many projects started on MySQL and moved to postgres. As did projects using mongo, couchdb, firebase, oracle etc etc…
And I’m sure many projects switched away from Postgres to other technologies. Right tool for the job at hand.
lmz 3 hours ago [-]
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.
atombender 2 hours ago [-]
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.
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).
https://multigres.com/
He is making a open source version of porting Vitesse to Postgres.
https://github.com/vitessio/vitess/graphs/contributors?from=...
it is not at all accurate to say that neki is made by "the team that brought you vitess" and that multigres is somehow not
> 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.
https://supabase.com/blog/multigres-vitess-for-postgres
Today I'm announcing I've cured cancer. Well not yet, but coming soon hopefully!
I'm a little surprised to hear that PlanetScale is doing the work to make this considering I thought their entire system was based on Vitess. Maybe the demand for Postgres compatible DBs is so high nowadays that they need to offer compatibility for customers that don't want to port their apps to MySQL's syntax?
https://youtu.be/y1aq8RsnJeI
Sugu hasn’t been at Planetscale for a few years
https://github.com/multigres/multigres
[1] https://vitess.io/docs/20.0/user-guides/configuration-advanc...
These are forks or extensions of Postgresql.
Feels like it might be very useful since a lot of new technologies came out since spinning disks.
The Postgres team is working on replacing Postgres. With even better Postgres.
And then to lesser degrees you've got Yugabyte, AlloyDB, and Aurora DSQL (and certainly more I'm forgetting) that only replace parts of Postgres.
The MVCC that Postgres uses(and no one else) is like 50yo outdated concept they still cling to. So just by virtue of that, it makes PGSQL the most archaic db on the market nowadays.
I never understood why PGSQL had so many fanboys, yet every major tech company always ditches it for mysql... i guess it is the case of "Any man who must say, "I am the King", is no true king." type of thing. People have to make a lot of noise to excuse their bad choices so they don't have to admit making a mistake.
Sarcasm aside, a great many projects started on MySQL and moved to postgres. As did projects using mongo, couchdb, firebase, oracle etc etc…
And I’m sure many projects switched away from Postgres to other technologies. Right tool for the job at hand.
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.