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.
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
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.
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.
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.
47 comments
[ 3.1 ms ] story [ 91.0 ms ] threadCome on, folks. Never put out a press release without a simple description about what your thing even is.
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.
If you have feedback or want to chat feel free to email me: sam@planetscale.com
This single feature would open up a lot of usage for me and many others I know.
Vitess was already one of the most performant distributed databases, this is really pushing the limits even further.
[1] https://github.com/vitessio/vitess/pull/7439#issuecomment-77...
https://aws.amazon.com/rds/postgresql/pricing/
https://azure.microsoft.com/en-us/pricing/details/postgresql...
Of course, the answer is that both are insane markups. But it's worth being able to focus on other things!
https://www.yugabyte.com/
https://www.cockroachlabs.com/
1: https://www.citusdata.com/blog/2021/03/13/scaling-out-postgr...
2. https://www.citusdata.com/product/comparison
[1]: https://www.planetscale.com/
Vitess was most definitely a special snowflake: most Google production servers don't even have disk anymore[0].
(There are a whole host of other reasons for doing Vitess->Spanner, all of which fall under "special snowflake infrastructure".)
[0] https://static.googleusercontent.com/media/sre.google/en//st... (see ch2, diskless)
MariaDB can use something similar called Galera Cluster. Percona also has its own version, called Percona XtraCluster (PXC).
For more traditional MySQL/MariaDB replication typologies, Orchestrator[2] is a great tool.
For postgres, I have heard a lot of good words about Patroni[3], although I never used it myself.
[1]: https://dev.mysql.com/doc/refman/8.0/en/group-replication.ht...
[2]: https://github.com/openark/orchestrator
[3]: https://github.com/zalando/patroni
I would appreciate any comments. Specially on the upsides and downsides.
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.
[1]: https://github.com/citusdata/pg_auto_failover
I noticed in their MIT like license it referred to Microsoft and was confused until I learned they were acquired.
https://github.com/citusdata/pg_auto_failover/blob/master/LI...