imjosh-dev

cross shard joins break down into single shard selects, and are joined in the routers. There are some query patterns that are currently unsupported, but we are working on adding support for them. The biggest thing to keep in mind when running on a sharded database of any kind is decreasing the number of cross shard queries.

Completely up to the user. Neki doesnt automatically shard, its all controlled by the data topology (https://planetscale.com/blog/what-is-a-data-topology).

I actually wrote a bit about this on our blog! https://planetscale.com/blog/the-history-of-postgres-shardin...

don't worry, we still give a lot of love to vitess. at the end of the day they are both databases. the beauty of doing both is we can take learnings from each product and apply it to the other.

https://neki.dev/ is a much more terse overview of neki

(Also PlanetScale employee here) Each shard finishes a backup at it's own time T, so two different shards could finish minutes apart (or even more, depending on the difference in size). for pretty much any use of a backup, you'll effectively be doing a PITR, not a raw restore from the cluster. The PITR timestamp is what unifies all the clusters together, regardless on when each backup finishes. think of backups as jumpstarts for actual restores (like for cluster resizes), where WAL replay and replication get the node to real time (or some specific point)

with that said you can restore without PITR if you don't care about synchronization, but generally you'll just use PITR

Author here, happy to answer any questions!