LatticeDB une grafo, vetores e busca textual num único banco local
O que é o LatticeDB
LatticeDB é um banco de dados embutido de property-graph com indexação vetorial nativa e busca textual completa. A proposta é resumida pelo próprio projeto como "pense SQLite, mas para dados conectados": tudo em um único arquivo e um motor local, com travessia de relacionamentos, similaridade vetorial, busca full-text BM25, streams duráveis e transações ACID na mesma camada de consulta. O projeto é distribuído sob licença MIT, escrito em Zig e sem dependências.
A instalação funciona por script de linha de comando, pip install latticedb (Python) ou pacote npm para Node.js, e a página promete começar em 30 segundos com exemplos completos nas duas linguagens.
Uma consulta, três modos de busca
O diferencial anunciado é combinar, em uma única consulta Cypher, busca vetorial, busca textual e travessia de grafo. O exemplo oficial busca trechos cujos embeddings tenham distância menor que 0,3 de um vetor de consulta, filtra documentos por conteúdo com o operador de full-text, percorre as relações até o autor e retorna ordenado pela proximidade vetorial.
Os snippets de criação e consulta mostram o padrão básico: nós Person, Document e Chunk conectados pelas relações PART_OF e AUTHORED_BY, com o embedding gravado direto no nó via API de transação (set_vector em Python, setVector em TypeScript).
Números de desempenho e suas ressalvas
O site declara: 0,13 µs para lookup de nó, 0,83 ms para busca de 10 vizinhos mais próximos sobre 1 milhão de vetores com recall de 100%, 19 µs para busca full-text (descrita como 300 vezes mais rápida que o FTS5 do SQLite) e travessias de grafo de 14 a 2.819 vezes mais rápidas que SQLite.
Nas comparações de busca vetorial, LatticeDB registra 0,83 ms contra 0,5–3 ms do FAISS HNSW, 1,4 ms do Weaviate, cerca de 1–2 ms do Qdrant, cerca de 5 ms e 99% de recall no pgvector, 4–5 ms no Chroma e cerca de 15 ms no Pinecone. Em travessia de dois saltos sobre 100 mil nós, LatticeDB marca 39 µs contra 548 µs do SQLite com CTE recursiva, 19 ms do Kuzu (arquivado em 2025) e 10 ms do Neo4j.
Há uma ressalva explícita: apenas a linha do SQLite foi medida head-to-head na mesma máquina; os demais números são figuras publicadas por terceiros. A página indica que guias de comparação detalham, de forma supostamente honesta, o que cada alternativa faz melhor.
Recursos por pilar
No grafo, há IDs de arestas estáveis, propriedades grandes via armazenamento de overflow em B+Tree, travessia multi-salto com padrões de comprimento variável validados e suporte a MERGE, WITH, UNWIND, LIMIT/SKIP por expressão e agregações.
Na busca vetorial, usa HNSW de vizinhos aproximados com parâmetros M e ef configuráveis, recall de 100% com 1 milhão de vetores e embeddings gerados por hash interno ou integrados ao Ollama e à OpenAI.
Na busca textual, há índice invertido ranqueado por BM25, tokenização e stemização, busca fuzzy por distância de Levenshtein.
Complementarmente, existem streams nomeados duráveis guardados em B+Trees de sistema, sequências por stream, offsets explícitos de consumidores, trim manual para retenção e um changefeed de grafo com resumos de valores grandes.
Novidades da versão 0.10.0
A versão traz três frentes. Primeiro, índices de propriedade duráveis para nós e arestas, usados pelo planejador Cypher em filtros de igualdade, mantidos por escritas diretas e transacionais e reconstruídos na recuperação - a consulta indexada nunca cai silenciosamente para varredura completa. Segundo, regras de posse de escrita: apenas uma transação de leitura e escrita ativa por handle, e um segundo escritor recebe erro de contenção em vez de competir, enquanto leituras podem coexistir; a posse de fechamento ficou consistente em todas as linguagens. Terceiro, devolução de espaço: exclusões em B+Tree rebalanceiam todos os níveis internos, o comando lattice compact trunca páginas livres do final do arquivo, a substituição de vetores e a reconstrução do HNSW reutilizam armazenamento, e cadeias vetoriais corrompidas persistidas são rejeitadas, não lidas.