The last version, 10, brought in a scan resistant cache (the PR is interesting [1]). It would have made a fun blog post. Hopefully they can write more about the internals when they make these types of improvements.
And yet it received enough votes to be on the front page, meaning enough visitors were aware of it or interested enough to spend 5 seconds investigating what it is!
May be I should have included it in the title. ( But HN also has a rule for title not being edited ).
It is too late now, HN was down for about an hour and it is now outside the editing window. And while I do agree there should be a description on the front page of any project ( I am usually the one one rant about it ), I dont think such description is necessary in every changelog or release note.
I heard that YouTube has migrated to Spanner already. YT was the last major user of MySQL at Google, the Googlers probably consider that as a snowflake and wanted to move away from it. Nothing wrong with Vitess itself.
For ring replication to work, it requires all replication sources (aka. "masters") to be online at all times. This never happens in real life, so it is just a matter of time that you get a nasty split-brain. Star replication tries to mitigate this by a crazy setup with replication filters that is painful to maintain and probably will break after some DDL statements.
Moreover, neither of these can handle conflicts. If a row gets updated on different hosts at the same time, you will get broken replication and/or split-brain.
To scale writes, sharding is usually the way to go and Vitess can be handy for that. By the way, MySQL group replication has multi-primary mode that is safer. Galera Cluster/PXC probably has something similar but I am not completely sure.
I would definitely say pg-auto-failover[1]. It's the only one that doesn't have a ton of moving parts, and it helps you get a good base setup too at the same time.
Just need something like this for postgres and we would jump on it. Citus is close, but all the features that are important are behind their exceptionally tall paywall.
We are seeing a bunch of folks moving away from Postgres over to MySQL + Vitess for this reason. Including a major website that we will be able to talk about soon.
For their hosted system, it's not particularly worse than hosted Postgres on RDS. RDS costs $0.50/hr for a 4 core/32GB db.r5.xlarge. Azure-hosted Citus for multi-node workloads on a similarly sized node are $0.618/node/hr. Both double in price to have a high availability backup cluster.
There's Yugabyte (top half of Postgres with bottom half proprietary DocDB data layer) or CockroachDB (completely new stack) if you just want scalable Postgres-flavored SQL.
Hey, I am sorry you had a bad experience on the platform. We released as a beta and have made rapid improvements. I am confident if you give us another try you will have a better experience.
If you have feedback or want to chat feel free to email me: sam@planetscale.com
Vitess was already one of the most performant distributed databases, this is really pushing the limits even further.