PlanetScale lança Neki, que distribui Postgres sem mudar SQL, drivers ou ORMs

Lançamento e promessa

O PlanetScale anunciou o Neki, um Postgres com sharding, disponível em prévia de plataforma. Segundo a empresa, o produto foi construído a partir de lições de oito anos operando alguns dos maiores clusters MySQL com sharding do mundo, com milhares de cargas de produção e milhões de consultas por segundo. Depois de lançar o PlanetScale Postgres há um ano e meio, a empresa viu equipes se aproximarem do teto de uma única máquina com Postgres; aumentar o hardware comprava tempo, mas não havia boa opção quando clientes atingiam o limite de uma máquina. O Neki permite escalar um banco Postgres por várias máquinas mantendo Postgres real em cada shard.

A aplicação se conecta a um roteador Neki pelo protocolo padrão do Postgres, então drivers, ORMs e a string de conexão existentes continuam funcionando. Cada shard é um cluster Postgres completo, com um primário e pelo menos duas réplicas em três zonas de disponibilidade. Não há engine de armazenamento customizada: extensões, suporte a SQL e desempenho se comportam como no Postgres. O usuário escolhe a shard key e controla como tabelas são agrupadas e distribuídas por uma topologia de dados em JSON. Mudanças de schema, upgrades de versão, failovers, importações e resharding rodam como workflows online. A oferta inclui recursos do PlanetScale, como Insights, recomendações de schema, branching e MCP.

Por que

A empresa descreve problemas comuns de bancos Postgres em crescimento: tabelas grandes demais para vacuum ou indexação sem afetar o tráfego, backups que levam horas, limites de conexão, janelas de manutenção para mudanças de schema e transaction wraparound. Mudar para uma instância maior ajuda, mas eventualmente faltam máquinas grandes o suficiente, e os problemas não crescem de forma linear conforme se adicionam núcleos e IOPS. As respostas existentes, diz o PlanetScale, exigem abrir mão de algo: sharding no nível da aplicação empurra o roteamento para o código; bancos distribuídos compatíveis com Postgres escondem a shard key, retiram extensões e adicionam complexidade e latência difíceis de tratar e depurar. O princípio central do Neki é permanecer no Postgres, sem contorná-lo, simulá-lo ou abandoná-lo.

Como funciona

O Neki tem quatro partes móveis. Os roteadores recebem a conexão da aplicação, falam o protocolo do Postgres e mantêm parser completo, planejador distribuído de consultas e buffering. Eles analisam a consulta, decidem quais shards devem executá-la e combinam os resultados em um único fluxo; podem escalar vertical e horizontalmente. Cada shard é Postgres real com um primário e ao menos duas réplicas, e os shards são organizados em grupos que permitem separar tabelas ou cargas. Perfis de configuração definem tamanho da instância, número de réplicas, armazenamento, parâmetros e extensões.

O connection pooling usa sidecars ao lado de cada instância Postgres. Como o Neki controla as duas pontas, roteador e Postgres, ele dimensiona os pools conforme a capacidade real de cada instância, em vez de estimar de fora, o que a empresa apresenta como vantagem sobre apenas colocar PgBouncer na frente. O control plane acompanha a saúde dos nós, executa switchovers planejados e failovers não planejados e coordena workflows de resharding, schema e upgrades. A topologia de dados, um JSON, mapeia tabelas lógicas para shards físicos, define shard indexes e grupos; os roteadores mantêm a topologia em cache e a consultam a cada plano.

Operações e prévia

O que normalmente exigiria uma janela de manutenção vira workflow integrado: provisionar nós de destino, colocá-los em dia por replicação, trocar o tráfego com uma metafunção __neki e aposentar os nós antigos, tudo pela mesma conexão psql usada pela aplicação. Isso cobre mudanças de schema, upgrades, failovers, importações e resharding. Também é possível rodar o Neki sem sharding, como primário único com réplicas, obtendo pooling melhor, DDL online, upgrades sem downtime e monitoramento antes de precisar fragmentar. Na prévia de plataforma, porém, a recomendação é não rodar cargas de produção, pois o produto ainda muda e algumas mudanças serão incompatíveis. Feedback pode ser enviado por ticket ou Discord. Para testar, basta entrar no PlanetScale, optar pela prévia e criar um cluster Neki.