[escardin]

> With vitess the sharding logic lives “in the database” so your application doesn’t need to be updated.

That is unfortunately not true in the majority of cases. Queries of medium complexity or higher will often just fail to run on vitess. You also still need a sharding key if you want queries to be efficient. Essentially you don't want the vtgates stitching tables from different shards together.

As you scale, scatter queries become more and more problematic. You need to have carefully considered lookups, and often alter your queries to include sharding keys everywhere.

Cross shard writes and two phase commits are also a recipe for deadlocks.

Finally, you need to keep in mind that every shard you connect to uses up a connection in its pool. If you have relatively long lived sessions (like... request length) that touch a ton of shards in the same query, you can exhaust your connection pool with 'idle' connections.

Vitess _is_ amazing. I am grateful for it every day. It is not a panacea. Neither are the alternatives. Switching to Vitess is a beautiful problem to have, because you have a problem of scale. The switch is harrowing.