Shard groups do Neki definem o co-location de tabelas relacionadas no mesmo cluster físico

Na documentação de design do Neki, a unidade de co-location é o shard group, não a tabela. Duas tabelas no mesmo grupo que fazem hash da shard key do mesmo jeito sempre colocam linhas com o mesmo valor no mesmo shard. No exemplo da loja, o grupo customer_data define um índice padrão by_customer sobre customer_id, com hash xxhash num espaço de 64 bits. Os key_ranges dividem esse espaço entre clusters físicos (store-1 e store-2). Para customers, que usa id como chave primária, o Neki permite herdar o índice padrão trocando só a coluna. Assim, pedidos, itens e endereços de um cliente ficam num shard só.

O ganho vai além da latência. Uma transação restrita a um shard mantém a semântica completa do Postgres. Se tocar dois shards, o Neki faz commit separado em cada um, sem commit atômico e sem snapshot compartilhado. Tabelas de consulta como countries, currencies e tax_rates viram reference tables, com cópia completa em cada shard do grupo. O workflow MoveTables carrega as cópias iniciais e o router replica todo insert, update e delete para todas elas. Para consultas sem shard key, como buscar orders por id, entra o global secondary index (GSI): uma tabela de lookup mantida pelo Neki que mapeia a coluna à shard key, o que custa duas leituras de shard único. O índice também aceita expressões SQL, como lower(sku) ou left(order_id, 4), e há os tipos range e modulo, este último desaconselhado em escala porque mudar o módulo move quase todas as linhas.

Em 11 de setembro de 2026, o CEVIU noticiou "Desvendando o PostgreSQL Sharded: A Jornada de uma Query em Sistemas Distribuídos", sobre o ciclo de vida de uma consulta. A fonte atual retoma esse exemplo: lá o router precisava juntar customers e orders sozinho porque cada tabela era shardeada pelo próprio ID. Agora a correção aparece com nome e configuração, o shard group, com orders shardeada por customer_id. Em 16 de outubro de 2026, a matéria "Neki Otimiza Queries Distribuídas no PostgreSQL com Gerenciamento de Sequências" tratou de outra parte do mesmo produto.

Para quem opera Postgres em escala, a leitura é que a escolha da shard key vira decisão de modelagem com impacto direto em transações e custo de consulta. Começar pelas queries críticas, e não pelas tabelas, tende a evitar fan-out e commits entre shards. Como o Reshard permite trocar chave ou número de shards depois, o erro inicial não é definitivo, mas migrar tem custo operacional.