GitHub limited to 16 database shards due to scatter query inefficiencies

GitHub's database architecture for pull requests and issues has been limited to only 16 shards across the entire platform. This constraint is driven by the prevalence of 'scatter queries,' which lack the primary key used for sharding and must hit every shard to return results. As the number of shards increases, these queries become linearly inefficient. The system runs on a large Rails monolith using ActiveRecord, which obscures the underlying SQL and makes it difficult to identify and optimize these inefficient queries. For example, the repository homepage previously required over 100 MySQL queries across at least three different clusters to populate, with most counts calculated live rather than cached. Engineers attempted to migrate data to a channel-based sharding model using Vitess, a MySQL wrapper, to improve horizontal scaling. However, the legacy scatter queries remained a significant bottleneck for performance and reliability, preventing further expansion of the shard count.