[bddicken]

A lot of what you're referring to is dictated by the sharding strategy. Vitess and Neki both let you configure this via the VSchema / data topology (That's what I'm getting at here)

https://planetscale.com/blog/making-768-servers-look-like-1#...

This decision matters a ton. I drilled into this specific point on sharding in one of my articles from awhile back:

https://planetscale.com/blog/database-sharding

This is something you face any time you shard data, no matter the system. Single-shard queries are preferred to cross-shard ones. We want 99% of what we do to be single shard, but occasionally cross-shard work is unavoidable.

[drdexebtjl]

> We want 99% of what we do to be single shard, but occasionally cross-shard work is unavoidable.

Why optimize for the 1% and put the logic in a database proxy, then? It’s a leaky abstraction.

Require the application to explicitly and loudly make a query for each shard and collate the results.

[kbrajesh176]

Exactly. sharding is for scaling usecase where queries can be handled within a shard(co-partitioning). If sharding strategy can assign keys from two tables where join is needed you can get achieve same performance.

In another usecase where joins are not needed realtime, you can build another system where results are precomputed and cached. I consider sharding as methodology for scaling instead of onefit all solution. Overall it depends on usecase and sound sharding strategy for performance.