Voltar

Jepsen encontra 96 problemas no ParticleDB 1.1.4, de perda de dados a resultados SQL incorretos

Aprofundamento CEVIU

Aprofundamento

O ParticleDB nasceu na Orkes para sustentar o Conductor, plataforma de orquestração de workflows que antes guardava dados em Redis e Postgres. A proposta é unificar SQL transacional, key-value, busca vetorial e analytics em um único motor escrito em Rust, com acesso pelos protocolos do Postgres e do Redis, além de gRPC e HTTP2. A Jepsen testou a versão 1.1.4 e seguintes, até a 1.1.18.11.rc-22, sempre em nó único, porque a replicação com Raft só existia em deployments enterprise na nuvem e não estava nas builds fornecidas.

O isolamento não se controlava por SET TRANSACTION ISOLATION LEVEL, que era ignorado ou rejeitado. Quem decidia era o parâmetro --txn-mode na inicialização (fast, occ, zero-copy-occ, table-2pl), e a documentação pública não explicava as garantias de cada um. A Orkes admitiu que parte dela estava errada. Também havia contradição sobre o modo de sync do WAL: a documentação dizia que sync dava durabilidade mais forte que groupsync, enquanto o help da CLI e o guia interno diziam que eram equivalentes. A home page falava em "formally proven" com TLA+, mas nenhuma especificação foi disponibilizada.

Os 96 problemas apareceram com workloads como rw e append (analisados com o verificador Elle), além de testes de consistência interna e de comparação direta com o PostgreSQL. Só três dos achados exigiram falhas; o resto ocorreu em instâncias saudáveis. Houve deadlocks, crashes sem mensagem de erro, lentidão extrema no table-2pl e falhas em prepared statements. A Orkes diz que uma release mais nova resolve os problemas, mas a Jepsen não verificou isso.

Por que isso importa

Para quem opera pipelines e modelagem sobre bancos novos, o caso mostra o custo de confiar em benchmark e marketing sem testar semântica. Um motor que diverge do PostgreSQL em resultados de SQL simples contamina qualquer camada analítica acima dele, e o erro tende a passar sem alarme. Antes de adotar, vale rodar uma comparação diferencial contra um banco de referência, como a Jepsen fez.

Perguntas frequentes

O que a Jepsen encontrou no ParticleDB?

Foram 96 problemas, incluindo perda de dados, crashes, deadlocks e resultados SQL incorretos. Quase todos ocorreram em instâncias saudáveis de nó único. Muitos foram corrigidos durante os testes, mas bugs graves em transações continuaram.

A replicação do ParticleDB foi testada?

Não. A replicação com Raft só estava disponível em deployments enterprise na nuvem, e as builds fornecidas à Jepsen não a suportavam. O relatório cobre apenas o comportamento em nó único.

Como se define o isolamento de transações no ParticleDB?

Pelo parâmetro --txn-mode na inicialização, não pelo SET TRANSACTION ISOLATION LEVEL, que era ignorado ou rejeitado. A documentação não explicava bem as garantias de cada modo. Segundo a fonte, occ-v3 e groupsync pareciam ser os padrões.

A versão mais recente corrige os problemas?

A Orkes afirma que sim, mas a Jepsen não verificou essa correção. Até haver novo teste independente, a afirmação segue sem confirmação.

Fontes

Avalie este artigo:
Categoria
CEVIU Dados
Publicado
02 de novembro de 2026
Editoria
CEVIU Dados

Quer receber mais sobre CEVIU Dados?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser