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.

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

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 ¯\_(ツ)_/¯

Does it literally repaint the terminal for the completion suggestions? Dang

You telling me we can make a ReactJS for terminals? ha

When will Postgres be supported?

Why is planetscale making release notes for vitess - a google project