Thanks for this. The site does a poor job of explaining what they actually do

I wonder how this stacks up against CockroachDB.

To the best of my knowledge the scaling behind distributed ranged KV stores (which cockroachDB uses as its storage engine) is easier to manage overall. Whether that's important for "serverless" is another question.

I'm sure PlanetScale will help with rebalancing and re-sharding but, just like FoundationDB, CockroachDB "promises" to automatically re-shard hot keys and ranges for you under the hood, and so _in theory_ scales well for a distributed read/write heavy system over many nodes with potential hotspots. My CockroachDB knowledge is based off of research into FoundationDB, but I think it shares many of the same underpinnings (even the record layer concept). And FoundationDB scales very well.

Vitess, on the other hand, manages the cluster for you but I don't think that the rebalancing and sharding is as easy to manage. Would love to learn more as I don't know much about Vitess.

Vitess using range based sharding and with a single command of `Reshard` you can split a range to n sub-ranges.

Ref for how command looks like https://vitess.io/docs/user-guides/configuration-advanced/re...

Happy to be wrong but both of you sound like you're commenting without any operational knowledge about either database technology.

Since I feel injustice done here, I'd like to point out that harshit164 is a Vitess maintainer who is my go-to person of reference for these exact topics, and who is authoritative about this database technology.

You must be very happy, then.

Where is the data hosted? Is it software to run it locally?

the page planetscale.com says their cloud or yours.

The referential integrity piece (otherwise known as Foreign Keys) will not be addressed and is a limitation - some might say feature - of Vitess. They wrote a pretty good piece about it here, https://docs.planetscale.com/tutorials/operating-without-for...

Thanks, that looks pretty useful.

To me, this means that planetscale (and vitess) immediately become less useful for a large class of applications: existing apps that use an RDBMS that you want to scale. Because most existing apps will expect FKs. I haven't tested my employer's application (which has FKs) to see what will happen, but I doubt it will be smooth sailing.

But there's probably plenty of greenfield development where teams would prefer to stick with standards like SQL rather than a proprietary noSQL language, and that seems like a great fit for this solution.

There is not and will never be a solution to the problem of horizontally scaling an application and database designed jointly for a single-box ACID RDBMS. You have to compromise something to get the scaling.

Depends on your definition of horizontally scaling and the inherent size limitations you would be willing to accept.

CitusDB for example handles this by allowing FKeys between tables that share the same partition key. However it's also not -as- scalable as Vitess or as georeplication friendly but for many uses that need "more than a single box" is probably enough scalability.

> You have to compromise something to get the scaling.

And the reason why is basically “physics”. The speed of light is pretty damn slow all things considered.

Until we find ways to make all the servers in the cluster have latency measured in something like picoseconds, something is gonna have to give.

What about CockroachDB and YugabyteDB?

What is the compromise of Cockroach DB?

Heavy toll on performance and is not really postgres. For the same workload pg can be up to 30x faster or more than cockroach. At some point of course, pg won't be able to keep up and the horizontal scaling of crdb will beat it.

I believe they use some statistical analysis and declared locality tags (from config) to group related cells of data on the same nodes and regions, but I don't know how effective that proves. Pure performance isn't a strong suit of CRDB as far as I can tell, but sometimes that works fine, and it does scale well horizontally.

It's not entirely accurate to say that Vitess "doesn't have" foreign keys. It doesn't enforce FK constraints cross-shard, but it can use FKs to group referential data together within a shard, and the MySQL backing that shard can enforce FK constraints.