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?
I feel the integrity of data is WAY more important than pure performance and scalability. This is why i always shunned planetscale [vitess] (make no mistake, i really like their product and they have a nice free tier). When the need for sharding comes you have probably "made it" and most likely can afford a deeper refactor both in application and database design.
That said, true FK support is a very nice addition. However it really pains me to you MySQL, as it has a baggage it carries and is not SQL compliant. Thats why i always go for Postgres instead.
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.
Not knowing what this was about, I immediately figured "planetscale.com" was some Space site and "Vitess 18" was a new moon discovered somewhere ¯\_(ツ)_/¯
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.
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
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.
"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.
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
I'll believe it when I see it. Millions of applications use MySQL, and Vitess has only matured and grown.
They said Java was done like five times. It's in the midst of another massive revival. I think the bet on MySQL is a solid one, and I think reasonable minds should be able to differ about this, so I can't bring myself to be as sure as you seem to be.
I can say this: Our app, built on Planetscale and MySQL's protocol, has been fantastic to work with. We run locally against MySQL and H2, and in prod against Planetscale. Everything works really well. Boost, replication, backups, branching, etc etc. We use all of them. Every feature works great, does exactly what it says on the tin. We have never had a single problem.
So, in theory, yes, these things are all on a timeline of some kind between life and death, but I find it very hard to believe MySQL or Vitess are near the end of theirs.
I don't really recall because I don't think our database has needed much on top of stock MySQL. Maybe JSON columns? I don't really care. Just being candid as a user; it has not worried me, no.
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.
??? 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
Well, you are welcome to do your own review and share the results. At the time we were deciding between all the major DB as a Service providers. Not everyone has the same architecture as Bluesky, and from reading the code it seems pretty mechanical and complex.
I'm welcome to simply ignore PlanetScale unless I want to learn MySQL or need some performance characteristics that only make a difference in rare cases. Even if it is good enough I don't want to read the MySQL docs. If PlanetScale wants their product to be more welcoming, they'll have to distance it more from Oracle than it is.
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.
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.
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.
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.
I wonder how practical it'd be to attempt using this now, or would I have to go through too many hoops or footguns?