Uma única tabela cresceu para vários bilhões de linhas e as escritas estão ficando lentas. Quais são suas opções?

Esgote primeiro as opções mais baratas: índices melhores, arquivamento de linhas frias, mover colunas grandes para fora e réplicas de leitura para a carga de leitura. Depois particione a tabela, normalmente por tempo ou por tenant, para que cada partição fique pequena e partições antigas possam ser descartadas instantaneamente. Sharding entre bancos separados vem por último, porque custa queries entre shards, transações distribuídas e rebalanceamento, e a escolha da chave de shard é muito difícil de mudar depois.

Primeiro eu descobriria o que está lento de fato, porque uma tabela grande não é automaticamente um problema. Normalmente é manutenção de índice em cada insert, ou alguns índices que ninguém usa, ou o autovacuum ficando para trás. Então começo pelos ganhos baratos: derrubar índices que nada usa, mover uma coluna grande de texto ou JSON para uma tabela lateral para as linhas principais ficarem compactas, e arquivar tudo mais velho que a política de retenção. Se ainda estiver grande demais de verdade, eu particiono, normalmente por tempo para dados de evento, o que mantém cada partição pequena, permite ao planner podar para a faixa relevante e transforma apagar os dados do ano passado em descartar uma partição em vez de um delete que roda por um dia. Sharding é o último recurso porque muda o modelo de programação: joins entre shards somem, transações viram distribuídas, e rebalancear é um projeto. Se eu fizer sharding, a chave recebe pensamento de verdade, já que fazer sharding de uma tabela de eventos por id de cliente te dá um shard quente no minuto em que um cliente é dez vezes maior que o resto.