KiviDB promete ser até 9 vezes mais rápido que o Redis mantendo compatibilidade total

KiviDB é um banco em memória escrito em Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) → que fala o protocolo do Redis, soma busca vetorial nativa e publica benchmarks próprios contra Redis, Dragonfly e KeyDB. Os números mostram ganho real em cache puro, mas a história é mais disputada em busca vetorial.

O que é o KiviDB

KiviDB é um banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → em memória escrito em Rust que se apresenta como alternativa a Redis e Valkey. Ele fala o protocolo RESP2 e RESP3, então clientes Redis, o redis-cli e bibliotecas existentes funcionam sem alteração. O projeto apareceu em um Show HN no GitHub, com o README documentando benchmarks, variantes de build e comandos de busca vetorial compatíveis com o Redis Stack.

A diferença central de arquitetura é como cada comando é processado. Redis roda em uma única thread com I/O em threads auxiliares; KiviDB distribui os comandos entre todos os núcleos, em um design sharded. Dragonfly também é shared-nothing entre núcleos, e é o concorrente mais próximo nos números publicados.

O servidor escuta por padrão na porta 6380, não na 6379 do Redis, o que permite rodar os dois lado a lado durante uma migração:

docker run -d -p 6380:6380 kividb/kividb
redis-cli -p 6380 PING # PONG

Os números do benchmark

Os testes, descritos como realizados em outubro de 2026 em instâncias AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → Graviton3 bare metal (um c7gn.metal de 64 vCPUs limitado a 32 núcleos), usaram o memtier_benchmark com 10 milhões de chaves e valores de 100 bytes. Com pipeline de 16 comandos, KiviDB 1.1.0 entregou 21,2 milhões de GETs por segundo, contra 9,1 milhões do Dragonfly 2.0.2 e 2,4 milhões do Redis 8.10 (4,7 milhões no Redis Cluster com 32 shards).

A latência de cauda acompanhou a diferença: p99 de 0,36 ms para GET e 0,42 ms para SET no KiviDB, contra 0,88 ms e 1,07 ms no Dragonfly, e 2,2 ms e 2,7 ms no Redis 8.10. Sem pipelining, porém, o quadro muda: Dragonfly chega a 3,35 milhões de GETs por segundo contra 3,07 milhões do KiviDB, uma diferença pequena a favor do concorrente. O uso de memória por chave ficou em 177 bytes no KiviDB, próximo dos 178 bytes do Redis e dos 183 bytes do KeyDB, mas acima dos 134 bytes do Dragonfly.

Em resumo: o ganho de throughput do KiviDB é real e expressivo em cenários com pipelining agressivo, que é como a maioria dos clientes de cache em produção realmente opera, mas ele não vence em todos os cenários nem é o mais econômico em memória.

Busca vetorial: onde a vantagem fica mais disputada

KiviDB implementa comandos FT.* no estilo Redis Stack, incluindo índices HNSW e FLAT sobre campos hash, com o mesmo formato de blob FLOAT32 little-endian usado por redis-py e NumPy. Na prática, quem já usa FT.CREATE e FT.SEARCH com Redis Stack migra o índice sem reescrever a aplicação:

redis-cli -p 6380 FT.CREATE idx ON HASH PREFIX 1 doc: SCHEMA \
 vec VECTOR HNSW 10 TYPE FLOAT32 DIM 128 DISTANCE_METRIC COSINE M 16 EF_CONSTRUCTION 128

O benchmark de busca vetorial, rodado com o redis/vector-db-benchmark sobre o dataset glove-25-angular (1,18 milhão de vetores, 25 dimensões, HNSW com M=16 e EF_CONSTRUCTION=256), mostra um quadro mais equilibrado que o de cache puro. Em ef 64, KiviDB processa 59,3 mil consultas por segundo com recall de 0,943, à frente do Dragonfly (41,3 mil) e do Redis 8.10 (31,8 mil). Em ef 512, porém, o Dragonfly assume a liderança em throughput, com 29,8 mil consultas por segundo contra 18,7 mil do KiviDB, mas é o KiviDB que mantém o recall mais alto (0,998 contra 0,995 do Dragonfly).

O tempo de ingestão e construção do índice também pesa contra o KiviDB: 31 segundos, mais que o dobro dos 13 segundos do Dragonfly, embora menos que os 38 segundos do Redis 8.10. Depois da ingestão, o KiviDB consome 1,66 GB de memória contra 1,13 GB do Dragonfly e 1,07 GB do Redis. Para quem está montando um pipeline de RAG↳RAG6 conteúdosTécnica RAG com a biblioteca Langchain: tutorial para aplicar agoraData · jun 2024Como avaliar LLMs, RAG e Agentes de IA: Teoria e prática.AI · abr 2026RAG Não É Memória: O Problema Real dos Agentes de IAAI · mai 2026Ver tudo em AI → com milhões de vetores, esse custo de memória e de tempo de indexação entra na conta tanto quanto a latência de consulta.

O que muda na prática para quem opera cache e busca vetorial

Para times no Brasil que rodam cache de sessão, filas de rate limit ou feature store em Redis, o apelo direto do KiviDB é reduzir o número de instâncias sem trocar código de aplicação. Se os números do próprio projeto se confirmarem em carga real, um único KiviDB rodando em 32 núcleos substituiria várias réplicas de Redis Cluster só para sustentar throughput de leitura, o que mexe direto na conta de infraestrutura em nuvem.

A compatibilidade de protocolo reduz o risco de migração: o README cita que o redis-cli e os testes de integração (em tests/e2e/) usam comandos binários seguros, iguais aos de qualquer cliente Redis padrão. Isso significa que trocar de engine é, em tese, uma mudança de endpoint e porta, não de biblioteca ou de query.

Dois pontos de atenção operacional merecem destaque antes de qualquer adoção:

• Modo protegido por padrão fora de container: como no Redis, o KiviDB só aceita conexões locais sem senha até que você configure --requirepass, --bind ou desligue o protected-mode. Isso é relevante no Brasil, onde vazamentos de instâncias Redis mal configuradas e expostas sem senha já geraram incidentes de segurança conhecidos.
• A imagem Docker inverte esse padrão: por rodar sempre via rede, o container sobe com --protected-mode no por padrão, e qualquer flag customizada que você passar substitui esse comportamento, podendo religar a proteção sem avisar. Vale revisar a documentação antes de publicar um container em produção.

Licença e build: o que observar antes de adotar

KiviDB é distribuído sob AGPL-3.0, a mesma licença adotada pelo Redis atual; o Valkey, por sua vez, oferece opções sob RSALv2, SSPLv1 ou AGPL-3.0. Segundo o próprio projeto, uma aplicação que se conecta ao KiviDB pela rede, por qualquer cliente Redis, é um programa separado e não herda obrigações da AGPL. A obrigação da licença só entra se alguém modificar o próprio KiviDB e oferecer essa versão modificada como serviço de rede para terceiros, caso em que o código da modificação precisa ser aberto.

Para quem não pode usar AGPL ou quer embutir o KiviDB sem publicar alterações, a empresa por trás do projeto, KIVIDB PRIVATE LIMITED, oferece uma licença comercial separada. É o mesmo modelo de dual-licensing que outros bancos de dados em Rust e C++ vêm adotando nos últimos anos para sustentar o desenvolvimento sem abrir mão do código aberto.

O binário tem quatro variantes de build via features do Cargo: a padrão (sem Lua nem TLS), lua (adiciona EVAL, SCRIPT, FUNCTION e FCALL), tls e full (as duas juntas). Scripts Lua e TLS não vêm habilitados por padrão, então times que dependem de scripting no Redis hoje precisam compilar ou baixar explicitamente a variante com --features lua antes de migrar.

O que ainda fica em aberto

Os números publicados vêm do próprio repositório do KiviDB, rodados em uma única sessão de outubro de 2026 em hardware específico da AWS (Graviton3), e o próprio projeto avisa que resultados dependem do ambiente e recomenda medir na carga de trabalho real antes de confiar neles. Não há, até aqui, benchmark independente de terceiros replicando esses números, nem relatos públicos de uso em produção em escala.

Também não está claro no material disponível qual é o comportamento do KiviDB em cenários de cluster multi-nó sob falha, já que os números de throughput foram medidos com o servidor sozinho, sem réplicas nem failover ativado durante o teste. Para quem avalia trocar de engine, a recomendação do próprio projeto é rodar o kivi-benchmark (documentado em benchmarks/LATEST.md) contra a carga real da aplicação antes de qualquer decisão.

Fonte

1. GitHub - kividbio/kividb: A fast, multi-threaded Redis® and Valkey alternative written in Rust

Fonte: Hacker News