Neki – Postgres Fragmentado

O que é Neki e posicionamento

• Descrito como um sistema PostgreSQL fragmentado com uma camada de roteador que adiciona indireção entre aplicativos e fragmentos do Postgres.
• Apresentado como “semelhante ao Vitess, mas para Postgres”, construído por engenheiros com experiência em Vitess, mas afirmado como uma implementação do zero para Postgres.
• Destinado a lidar com refragmentação online e cargas de trabalho em grande escala; funciona apenas como um serviço gerenciado pelo provedor, não “em qualquer lugar”.

Documentação, mensagem e marketing

• Muitos leitores tiveram dificuldade para entender “o que é Neki” a partir do blog de lançamento; a landing page foi vista como mais clara.
• Alguns acharam que a postagem carecia de uma descrição top-level concisa e de garantias de consistência; edições posteriores adicionaram uma seção “What is Neki” e, por fim, redirecionaram para a página de marketing.
• Design e branding receberam elogios, mas alguns ainda acharam o modelo do produto (totalmente gerenciado vs auto-hospedado) अस्पष्ट.
• Alguns comentários observaram marketing coordenado (anúncios, múltiplas postagens no HN).

Fragmentação, transações e consistência

• Questões sobre:
  • Como funcionam joins e transações entre fragmentos.
  • Se chaves estrangeiras e constraints entre fragmentos são suportadas.
  • Modelo de consistência (forte vs eventual, opções de read-after-write, atraso de réplica).
• Representantes dizem:
  • Existem transações entre fragmentos, mas ainda não com 2PC totalmente atômico; isso está em andamento.
  • O roteador não compartilha código com o Postgres.
• Vários pedem uma página clara de garantias e diagramas de arquitetura/C2; os docs atuais foram chamados de “AI-like” ou vagos por alguns.

Lacunas de recursos e áreas pouco claras

• Chaves estrangeiras e constraints entre fragmentos parecem ausentes; alguns comparam isso a versões antigas de outros bancos de dados distribuídos.
• O tratamento de tabelas muito grandes (por exemplo, mais de 8 bilhões de linhas) e se uma única tabela pode abranger vários fragmentos não está claro.
• O comportamento de consistência e cenários de falha não estão totalmente documentados no thread.

Debate entre open source e proprietário

• Vários comentaristas se importam fortemente com open source para segurança de longo prazo e risco de fornecedor; alguns dizem não ter interesse em código fechado.
• A empresa está “indecisa” sobre tornar Neki open source, mas enfatiza a necessidade de proteção contra grandes provedores de nuvem replicarem o serviço.
• Alguns apontam a ironia de a própria empresa ser construída sobre um projeto open source enquanto mantém o Neki fechado.

Comparações com outros sistemas

• Comparações foram feitas com: Citus, Multigres, pgdog, a oferta da Supabase, Aurora, Cloud SQL, Spanner, Vitess/PlanetScale MySQL, MariaDB Galera, TiDB.
• Representantes enfatizam que o Neki já suporta fragmentação e refragmentação online, ao mesmo tempo em que afirmam que alguns concorrentes ainda não têm fragmentação madura.
• Projetos open source concorrentes destacam os benefícios de serem auto-hospedáveis e não proprietários.

Percepção da cultura da empresa e do tom

• Houve uma discussão paralela significativa sobre o comportamento público do CEO e posts criticando concorrentes.
• Alguns acham o estilo agressivo e sarcástico divertido ou refrescantemente honesto; outros o veem como pouco profissional, desagradável ou um motivo para evitar o produto.
• Debate sobre se a defesa confrontacional de um modelo comercial/open-core é justificada ou contraproducente.