Neki: o Postgres distribuído da PlanetScale para apps que cresceram

O que é Neki

Neki é uma plataforma de Postgres distribuído criada pela PlanetScale. A proposta é espalhar um banco de dados por várias máquinas sem trocar o Postgres real por um mecanismo proprietário ou exigir que o roteamento fique todo dentro da aplicação.

O anúncio foi feito em 10 de setembro de 2026. A ferramenta está disponível em Platform Preview, uma fase de avaliação que permite testar o produto, mas ainda não é indicada para cargas de produção porque mudanças incompatíveis podem acontecer.

O problema atacado é conhecido por equipes que cresceram rápido: uma única máquina começa a limitar vacuum, índices, backups, conexões e janelas de manutenção. A PlanetScale diz ter aplicado ao Neki as lições de oito anos operando clusters MySQL particionados em grande escala e, depois, de acompanhar clientes que chegaram ao limite de uma única máquina com Postgres.

Como funciona

A aplicação se conecta a um roteador Neki usando o protocolo de comunicação do Postgres. Por isso, a ideia é preservar a connection string, os drivers e os ORMs que a equipe já usa. O roteador interpreta a consulta, monta um plano e decide em quais shards o trabalho precisa ser executado.

Cada shard é um cluster Postgres completo, com um primário e pelo menos duas réplicas distribuídas por três zonas de disponibilidade. O Neki adiciona sidecars para ajudar no pool de conexões e um plano de controle para acompanhar a saúde dos nós, coordenar failovers e executar fluxos operacionais.

A distribuição é descrita por uma topologia de dados em JSON. Nela, a equipe define a chave de shard, os grupos de shards e a forma como as tabelas serão mapeadas. O produto também pode começar sem sharding, com um primário e réplicas, e evoluir quando os dados e o tráfego justificarem a mudança.

Principais recursos

O recurso central é o sharding horizontal: diferentes partes dos dados podem viver em grupos distintos de shards, enquanto a aplicação continua falando com um endpoint. Isso cria um caminho para crescer além da capacidade de uma única máquina sem reescrever todo o acesso ao banco.

O Neki também reúne operações que normalmente exigem uma janela de manutenção. A documentação cita alterações de esquema, atualizações de versão, failovers, importações e resharding como fluxos coordenados e executados enquanto o cluster permanece online.

Além da distribuição, a plataforma oferece roteamento de consultas, pool de conexões com conhecimento da topologia, monitoramento de saúde, Insights, recomendações de esquema, branching e integração com MCP. A combinação é interessante porque une a familiaridade do Postgres com controles para uma arquitetura distribuída.

• Topologia explícita: a equipe consegue revisar como tabelas e grupos são distribuídos.
• Postgres real: extensões e suporte SQL continuam baseados no próprio Postgres.
• Crescimento gradual: é possível começar sem shards e reshardar depois.

Como começar: instalação ou acesso passo a passo

O Neki não é apresentado como um pacote para instalar localmente. O acesso ocorre pela plataforma PlanetScale e exige que um administrador da organização aceite os termos do Platform Preview antes de criar um banco desse tipo.

O caminho inicial é simples: entre na conta PlanetScale, abra as configurações da organização, aceite a participação no Platform Preview e selecione Neki como mecanismo de banco. Em seguida, crie um cluster de teste e copie a connection string fornecida pela plataforma.

Depois, conecte uma ferramenta Postgres conhecida e rode uma carga pequena, representativa e descartável. O comando abaixo mostra a ideia sem expor credenciais; o valor de DATABASE_URL deve vir do painel da sua organização.

psql $DATABASE_URL

Antes de migrar dados reais, leia a documentação de arquitetura e de quando particionar. Durante o Preview, trate o ambiente como experimental, registre as decisões da chave de shard e teste restauração, mudança de esquema, failover e consultas que podem atingir mais de um shard.

Exemplo prático

Imagine um SaaS de gestão com muitas empresas clientes. A maioria das consultas usa tenant_id, e cada cliente precisa enxergar apenas seus próprios projetos, usuários e eventos. Nesse cenário, tenant_id pode ser um candidato natural a chave de shard, desde que a equipe valide distribuição, tamanho dos clientes e risco de concentração.

O primeiro passo é manter as operações de cada cliente localizadas. O exemplo abaixo é didático: ele cria uma tabela de eventos e grava dados de duas empresas. A configuração real da topologia deve ser feita no Neki e revisada com dados de produção anonimizados.

CREATE TABLE eventos (id BIGSERIAL PRIMARY KEY, tenant_id TEXT NOT NULL, tipo TEXT NOT NULL, criado_em TIMESTAMPTZ NOT NULL DEFAULT now()); INSERT INTO eventos (tenant_id, tipo) VALUES ('empresa-a', 'login'), ('empresa-b', 'exportação'); SELECT tipo, criado_em FROM eventos WHERE tenant_id = 'empresa-a' ORDER BY criado_em DESC;

Na prática, a equipe observaria o plano das consultas, o tamanho de cada tenant, a taxa de escrita e a frequência de consultas globais. Consultas por tenant tendem a ser mais fáceis de rotear; relatórios que cruzam todos os tenants exigem análise específica para não transformar o roteador em um novo gargalo.

A vantagem do desenho é que o código continua usando um driver Postgres. A responsabilidade nova fica na arquitetura de dados: escolher uma chave estável, definir grupos coerentes e testar o comportamento de consultas que não carregam a chave de shard.

Comparação com alternativas

A primeira alternativa é continuar com Postgres em uma máquina maior, adicionando réplicas e melhorando índices, pool e consultas. Essa opção é mais simples e deve ser a escolha inicial quando o problema ainda pode ser resolvido verticalmente ou com ajustes operacionais.

Outra alternativa é fazer sharding na própria aplicação. Ela dá controle direto sobre o roteamento, mas espalha regras de distribuição pelo código, aumenta a superfície de testes e torna migrações mais trabalhosas. Bancos distribuídos compatíveis com Postgres podem esconder parte dessa complexidade, mas podem limitar extensões, comportamento SQL ou facilidade de diagnóstico.

Para workloads MySQL, a PlanetScale também mantém o Vitess. O Neki segue outra linha: foi construído especificamente para os desafios de escala e operação do Postgres. A escolha depende do banco existente, do padrão de consultas, da equipe e do nível de controle que a aplicação precisa manter.

• Postgres vertical: use quando há espaço para otimizar e a simplicidade pesa mais.
• Sharding na aplicação: use quando o domínio tem uma separação clara e a equipe aceita manter o roteamento.
• Neki: avalie quando o limite de uma máquina é real e o protocolo Postgres precisa ser preservado.

Pontos positivos e limitações

O ponto forte mais evidente é manter Postgres real em cada shard. Isso reduz a distância entre o que a equipe conhece e o que será operado, inclusive no uso de drivers, ORMs, SQL e extensões compatíveis com o Postgres de cada cluster.

Outro benefício é o modelo de operações online. Resharding, alterações de esquema, upgrades e failovers aparecem como workflows coordenados, o que pode reduzir janelas de manutenção e scripts artesanais em ambientes grandes.

A limitação decisiva é o estágio do produto. O Neki está em Preview, não tem garantia de estabilidade de produção e pode receber mudanças incompatíveis. Também não elimina decisões difíceis: uma chave ruim cria hotspots, consultas sem chave podem tocar muitos shards e a topologia passa a ser parte importante do contrato operacional.

O site do Neki ainda lista transações entre shards como recurso futuro. Portanto, aplicações que dependem de atomicidade cruzando vários grupos precisam manter o desenho transacional local ao shard ou esperar confirmação oficial de suporte antes de adotar esse padrão.

Casos de uso reais

Um primeiro perfil é o SaaS multi-tenant que cresceu e concentra quase todas as consultas por cliente. A equipe pode testar uma topologia em que dados de cada tenant sejam roteados de forma previsível, sem duplicar a lógica de seleção de banco em cada serviço.

O segundo perfil é uma plataforma de eventos ou telemetria que grava continuamente e já esbarrou em limites de índices, vacuum, backups ou conexões. O Neki pode ser avaliado como uma forma de distribuir a carga, desde que o padrão de escrita não concentre tudo em uma única chave.

O terceiro perfil é uma empresa com um Postgres grande que precisa de upgrades e alterações de esquema sem longas janelas. Os workflows online podem ser valiosos mesmo antes de a equipe decidir particionar os dados.

O quarto perfil é uma equipe que ainda não precisa de shards, mas quer um caminho de crescimento com a mesma interface. O início sem sharding permite experimentar pool de conexões, observabilidade e operações gerenciadas antes de adotar uma topologia distribuída.

Dicas e boas práticas

O maior ganho vem de tratar sharding como uma decisão de produto e operação, não como uma troca de servidor. Antes de criar a primeira topologia, liste as consultas críticas, seus filtros, o volume por entidade e os casos que exigem agregação global.

Por fim, automatize o que for possível ao redor do banco: migrações versionadas, testes de restauração, métricas por shard, alertas de saturação e uma rotina para revisar a topologia. A operação distribuída fica mais segura quando cada mudança é reproduzível e observável.

Vale a pena?

Para equipes que já atingiram o limite operacional de um único Postgres, o Neki merece uma avaliação técnica. A combinação de Postgres real, connection string conhecida, roteamento e workflows online ataca dores que normalmente aparecem quando o banco se torna parte crítica do produto.

Para uma aplicação pequena, uma consulta lenta ou um banco que ainda cabe com folga em uma máquina, a complexidade não se justifica. Começar com Postgres tradicional, índices corretos, réplicas e monitoramento continua sendo o caminho mais previsível.

O próximo passo é ler a documentação oficial, criar um ambiente de teste e comparar o comportamento com seu workload real. Como o produto está em Platform Preview, a decisão de adoção deve esperar validação de estabilidade, compatibilidade, suporte e condições comerciais antes de qualquer uso crítico.