Shard design doesn't start from your tables

This post introduces and details the concept of 'shard groups' in PlanetScale's Neki sharded Postgres solution. It explains how shard groups enable co-location of related tables on the same shard by defining default shard indexes (e.g., `xxhash`, `range`, `modulo`) and mapping keyspace ranges to physical shards. It also describes how to designate tables as 'reference tables' that are replicated across shards within a shard group. The post introduces Global Secondary Indexes (GSIs) as a mechanism to efficiently query tables that are not directly sharded by their primary key, by maintaining a lookup table. It also touches upon the `MoveTables` and `Reshard` workflows for data migration and re-configuration. The core technical contribution is the detailed explanation and configuration examples for designing shard groups based on query patterns to optimize performance and transactional locality.