[HN Gopher] Vitess 18
___________________________________________________________________
Vitess 18
Author : ksec
Score : 85 points
Date : 2023-11-07 17:55 UTC (5 hours ago)
(HTM) web link (planetscale.com)
(TXT) w3m dump (planetscale.com)
| IceWreck wrote:
| Why is planetscale making release notes for vitess - a google
| project
| nilslice wrote:
| i believe the creators of the Vitess project originally founded
| Planetscale
| Operyl wrote:
| As far as I know, they're the primary stewards for the project
| because the founders are the guys that made Vitess.
| capableweb wrote:
| Seems Vitess is a CNCF/Linux Foundation project?
| samlambert wrote:
| We (PlanetScale) are the maintainers of Vitess.
| caniszczyk wrote:
| Vitess is an open source and openly governed CNCF project
|
| https://landscape.cncf.io/?selected=vitess
| jetru wrote:
| Interesting, foreign key constraints typically make sharding
| harder, interesting to see them add support for some type of fkey
| constraint (even though it's same-shard only) to the db. I wonder
| how it impacts use-cases like vreplication/online DDL - I suppose
| you have to be careful with the exact semantics of the fkeys.
| ik8s wrote:
| It's great to see support for foreign keys, at least for FKs in
| the same shards. I've been wanting to explore PlanetScale
| (Vitess) for a while and the lack of support for FK was a blocker
| because the application currently relies on them.
|
| I wonder how practical it'd be to attempt using this now, or
| would I have to go through too many hoops or footguns?
| tbarn wrote:
| Just wait until December, we will release more information
| about foreign key constraints on PlanetScale then!
|
| It shouldn't be too many hoops, fairly standard foreign key
| constraint support. Let us (PlanetScale) know if it is!
| samlambert wrote:
| FKs will be available on PlanetScale within weeks so it's
| probably worth just waiting.
| aantix wrote:
| When will Postgres be supported?
| tristan957 wrote:
| If you want something similar to Planetscale, but Postgres, you
| can check out Neon, which is where I work in the interest of
| transparency.
| samlambert wrote:
| Quite a stretch to say similar. Neon does not support
| sharding, Boost, or scale to anywhere near PlanetScale as
| reliably.
| nikita wrote:
| Neon will stay true to Postgres. Our storage is sharded and
| bottomless. You can get a ton of TPS scale with large
| Postgres compute plus read replicas.
|
| Shared nothing architectures are useless for 99% of the
| market and break compatibility with the single node
| databases.
| sgammon wrote:
| As a user of PlanetScale I don't know what distinction
| you are making here and why.
|
| I've never had compatibility issues with single-node
| databases. It "just works" in the cloud and locally
| thanks to MySQL support in vitess.
| samlambert wrote:
| > Our storage is sharded and bottomless.
|
| Anyone can claim this and LVM together 20 64TiB EBS
| volumes and put them on one big node. That's not sharding
| or bottomless.
|
| Sharding and a shared nothing have incredible benefits to
| anyone who has a requirement for uptime, scalability, and
| cost reduction. We've avoided supporting parts of MySQL
| that make scaling worse and are working to add them back
| in ways that work, like FKs. In return for not supporting
| all MySQL features we hand back an immense amount in
| return. This is something our customers have been happy
| with.
| nikita wrote:
| Neon doesn't use EBS volumes. That's why it has an
| inherent cost advantage over Planetscale.
| sgammon wrote:
| Not to mention the 99.8% uptime at Neon, which is
| shocking. Look, if you are going to bring percentages,
| make sure they are the right ones.
|
| https://www.planetscalestatus.com/
|
| https://neonstatus.com/
| tristan957 wrote:
| FWIW, our uptime is definitely something we are
| prioritizing.
| sgammon wrote:
| Of course... this is a Vitess/Planetscale post or I
| probably wouldn't have even brought it up. All of these
| products are constantly undergoing change. They embody
| the best intentions and dreams of very smart people, such
| as yourself.
|
| I believe Neon will be one of the providers that sticks
| around to do this. Comparison is the thief of joy.
| nikita wrote:
| Our uptime will improve. We have been keeping up with the
| growth (2500 databases are created per day). And I
| insisted to be fully transparent on uptime.
|
| There is a ton of work internally that will improve the
| uptime as we get to GA.
| sgammon wrote:
| Having tried Neon, it's not really a replacement for
| Planetscale. PS' in-cloud features are hard to replace. In my
| review, PS won on a feature and cost basis.
|
| I think PlanetScale is the most mature option on the market
| right now by far
| tristan957 wrote:
| I agree that Planetscale is a very mature offering. Neon is
| technically in preview still, but we are actively working
| on the maturity of our offering every day. The success of
| Planetscale to date is definitely a position many database
| vendors want to attain.
|
| I don't think _won_ is the right term. _In the lead_ would
| be a better phrase in my opinion. I think Planetscale being
| based on MySQL will hurt them in the long run. Tying
| themselves to Orcale is already hurting them, having to
| fork MySQL to add vector support for instance. Neon, on the
| other hand, gets to benefit from a larger and much more
| collaborative community in Postgres, as do other Postgres
| vendors like Supabase, Azure, AWS, Tembo, Nile, etc.
|
| Please continue to use the vendor that you find works for
| you, however.
| sgammon wrote:
| "Won" is a statement which is accurate for the moment in
| which I did my review. I think all of these database
| providers are great.
|
| Postgres people need a solution just as much as MySQL
| people do. I think when it comes to Postgres, the name in
| my mind is Neon, even though I am a Planetscale customer.
| In my current job, I need MySQL, but to be clear I
| wouldn't be against Neon (even as a PS fan) if I had a
| direct need for it.
|
| Neon has a reason to exist even if Planetscale is in the
| "lead." There is a huge community around Vitess,
| including, you know, YouTube, not to mention MySQL, which
| also has an enormous community.
|
| Keep up the good work. Databases as a service are a good
| thing to be doing.
| throwusawayus wrote:
| youtube migrated away from vitess several years ago
|
| Mysql product is circling drain under oracles direction
| anymore. New 8.x "innovation" releases lack any important
| features. even Mariadb is out executing oracle despite
| being broke!
|
| Mysql community is in bad shape too. Official slack
| channel is avalanche of lazy newbie questions. Official
| linkedin group is endless spew of "learn sql cheat sheet"
|
| Sad. It's done for. community may still be "enormous" but
| that is bad thing when its communication channels overrun
| by sub-bootcamp-level devs
| correct_beans wrote:
| Nobody cares. Millions of apps run on mysql despite your
| objections. Good luck with that one
| benatkin wrote:
| Not accurate IMO. It's marketing a feature for giant
| users like YouTube and GitHub as important for everyone.
| Neon and sqlite are winning from my perspective. The
| BlueSky move to thousands of sqlite databases should
| inspire similar architectures in other apps. Vercel has
| stopped gushing about PlanetScale in particular and now
| offers never options including Neon.
| correct_beans wrote:
| ??? Bluesky isn't at all a typical application
| architecture. The code is gross and insanely complex for
| a regular app. Vercel still gushes all the time about
| Planetscale, and so does Cloudflare. Neon is the provider
| du jour _for postgres_
| billythemaniam wrote:
| CockroachDB and Yugabyte are Postgres compatible. GCP Spanner
| also has a Postgres compatibility layer. CockroachDB and
| Spanner support foreign keys across shards which is an
| interesting feature.
| Icathian wrote:
| You probably want to check out Greenplum for the postgres
| equivalent to this.
| andrewmutz wrote:
| Isn't Greenplum intended for OLAP style workloads? I believe
| Vitess is intended to be used for OLTP workloads.
| Icathian wrote:
| It works quite well for OLTP too. It's just that a lot of
| engineering effort went into features to make it workable
| for olap, which admittedly means that those hours didn't go
| towards further improving OLTP features. Overall though
| it's quite commonly used for both.
| shawnz wrote:
| I believe Citus is the closest alternative for Postgres.
| ugh123 wrote:
| Not knowing what this was about, I immediately figured
| "planetscale.com" was some Space site and "Vitess 18" was a new
| moon discovered somewhere -\\_(tsu)_/-
| samlambert wrote:
| If we ever have some spare marketing budget we will try and
| discover a moon for you.
| ugh123 wrote:
| Too bad "io" is already discovered :)
| getcrunk wrote:
| So while searching for something like this for postgres I came
| across citus. Any one know how that stacks up?
|
| https://github.com/citusdata/citus
| ge96 wrote:
| Does it literally repaint the terminal for the completion
| suggestions? Dang
|
| You telling me we can make a ReactJS for terminals? ha
___________________________________________________________________
(page generated 2023-11-07 23:01 UTC)