Apresentando o HotKV

O HotKV é um armazenamento de dados multithread e compatível com Redis, escrito do zero em C++ moderno e criado para extrair o máximo de velocidade de servidores modernos com muitos núcleos pelo menor custo possível. Sou Norbert E. Boros, fundador e CEO da HotKV Ltd. Este artigo explica por que o criei, o que ele faz hoje e como foi medido.

Em resumo. O HotKV executa comandos em muitas threads ao mesmo tempo dentro de um único processo e fala RESP2 e RESP3, o protocolo do Redis. No nosso benchmark de instância única de outubro de 2026, em 160 vCPUs, ele teve o maior throughput em 11 dos 12 comandos que medimos, e o Dragonfly ficou no mesmo nível no décimo segundo. A configuração e os limites dela estão descritos abaixo.

Por que criei o HotKV

Eu me importo com velocidade em tudo o que construo. Um site, uma ferramenta ou um servidor deve responder na hora, e quando isso não acontece, quero saber por quê. Esse hábito moldou o meu trabalho desde que comecei a escrever software.

C e C++ são as minhas principais linguagens há muitos anos. Por quase dez anos trabalhei em software anti-cheat para jogos que rodava nos PCs de milhares de jogadores. Ele precisava varrer a memória em busca de cheats usando o mínimo possível de CPU e de memória, porque cada ciclo que ele gastava era tirado do jogo. Esse trabalho me ensinou a medir tudo, a projetar pensando no hardware e a tratar o baixo consumo de recursos como uma qualidade por si só.

Paralelamente, usei o Redis e o Valkey em muitos projetos que precisavam de um cache rápido: armazenamento de sessões, listas de endereços IP bloqueados por um firewall e um cache na frente de centenas de milhões de registros do SQL Server. São ferramentas excelentes. Elas também me deixaram curioso sobre o que um armazenamento chave-valor poderia fazer se fosse projetado desde o início para os servidores com muitos núcleos que usamos hoje.

O HotKV é a resposta a que cheguei. Eu o escrevi do zero em C++ moderno para extrair o máximo de velocidade possível do hardware, pelo menor custo possível. O benchmark abaixo mostra onde ele está hoje, e espero que ainda haja mais a ganhar.

O custo da IA

Havia também um segundo motivo. Rodar aplicações de IA estava ficando caro, para mim e, a julgar pelo que os desenvolvedores compartilhavam na internet, para muitos outros também. Grande parte desse custo costuma vir de enviar a um modelo perguntas que ele já respondeu. Um armazenamento rápido que reconhece uma pergunta repetida ou parecida e a responde a partir do cache é uma das formas mais diretas de reduzir essa conta, e é por isso que o cache para cargas de trabalho de IA é uma parte central do HotKV.

Para que serve o HotKV

A HotKV Ltd existe para tornar esse tipo de software mais performático e mais acessível. Servidores modernos têm muitos núcleos, e um armazenamento de dados deve usá-los, para que você tenha o máximo de velocidade possível pelo menor custo possível.

A segunda ideia é manter mais da stack em um só lugar. Equipes que criam sobre LLMs costumam acabar operando um cache, um banco de dados vetorial e algum lugar para guardar a memória de agentes, com um monte de código de integração entre eles. Quero que o cache e o trabalho de IA construído em torno dele vivam em um único motor, ao lado dos seus dados: cache exato e semântico de chamadas ao modelo, busca vetorial, memória de agentes e orçamentos de tokens. Menos sistemas para operar deve significar menos peças móveis e uma conta menor. A página de IA lista o que está disponível hoje, e o benchmark de economia de tokens mostra quanto o cache de chamadas ao modelo economizou no nosso teste.

O HotKV mantém o protocolo do Redis e as bibliotecas de cliente já conhecidas.

O problema

Uma única thread de execução de comandos pode virar um gargalo em uma máquina com muitos núcleos. Um armazenamento de dados construído em torno de uma única thread de execução costuma alcançar o restante da máquina rodando várias instâncias ou um cluster, e isso traz consigo decisões de implantação e trabalho operacional. Eu queria que o HotKV partisse do lado oposto, com os comandos sendo executados de forma concorrente dentro de uma única instância, para que um só processo possa usar a máquina inteira.

O que o HotKV faz de diferente

O HotKV™ é escrito em C++20 e projetado para executar comandos em muitos núcleos ao mesmo tempo, de modo que uma única instância possa aproveitar uma máquina inteira. O Dragonfly, que incluímos no benchmark abaixo, também adota uma abordagem multithread.

• Muitos núcleos, uma instância. Os comandos são executados de forma concorrente pelos núcleos da máquina, então uma instância pode usar um servidor grande em vez de vários menores.
• Clientes e protocolo familiares. O HotKV oferece suporte a RESP2 e RESP3, então bibliotecas de cliente conhecidas podem se conectar a ele. Transações (MULTI/EXEC) e scripts em Lua são suportados. Consulte a documentação dos comandos para ver os comandos compatíveis e as eventuais diferenças.

Como ele é construído e testado

Eu mesmo construo o HotKV e uso assistência de IA onde ela ajuda. O que importa mais do que a forma como uma linha foi escrita é se ela se sustenta, por isso o motor é testado a fundo. Ele tem mais de 2.000 testes automatizados e é compilado com AddressSanitizer, ThreadSanitizer e UndefinedBehaviorSanitizer. Também tem alvos de fuzzing para o parser do protocolo, o despacho de comandos, o carregamento de RDB e AOF, o fluxo de replicação e o barramento do cluster.

A configuração do benchmark, os limites dela e os resultados completos estão na página de Desempenho, para que você mesmo avalie os números.

Resumo do benchmark

Atualizado em outubro de 2026: os números publicados originalmente neste artigo vinham de execuções de benchmark que depois constatamos serem falhas (entre outras coisas, todos os geradores de carga usavam a mesma seed aleatória), então os substituímos por resultados do nosso benchmark reconstruído.

Outubro de 2026: HotKV, Redis, Valkey e Dragonfly

A HotKV Ltd executou este benchmark. Medimos o HotKV, compilado a partir do código-fonte, contra o Redis 8.10.2, o Valkey 9.1.2 e o Dragonfly 2.0.2. Cada servidor rodou sozinho, como uma instância única, em todas as 160 vCPUs de uma Azure D160alds_v7 (AMD EPYC 9V45), com a persistência desativada. Três máquinas separadas de 64 vCPUs geraram a carga com o memtier_benchmark: valores de 256 bytes, profundidade de pipeline 30 e 5.000.000 de chaves previamente gravadas. Cada valor é a mediana de três execuções de 10 segundos.

O HotKV teve o maior throughput em 11 dos 12 comandos. Contra o Redis ou o Valkey, ele registrou entre 8,6 e pelo menos 69,7 vezes o throughput deles, dependendo do comando e do servidor; contra o Dragonfly, entre 1,97 e 4,41 vezes nesses 11 comandos, vários deles como limites inferiores. No PING, o Dragonfly ficou 0,6% à frente. Consideramos isso um empate, porque os geradores de carga estavam perto do próprio limite. O maior valor em um comando de dados foi de 90,8 milhões de operações INCR por segundo. INCR e PING movimentam poucos dados e são limitados pelos geradores de carga, então o valor do próprio HotKV para eles pode ser maior.

Como ler a tabela

O MGET lê oito chaves e o MSET grava quatro pares chave-valor por comando, e o throughput conta comandos. O relatório marca sete valores do HotKV (GET e seis comandos de escrita) porque eles atingiram o limiar de 85% de uso da rede, e o PING porque os geradores de carga estavam acima de 85% de CPU. As razões calculadas a partir deles são limites inferiores, marcadas com ≥. No GET e no PING, os limites são reais. Nos seis comandos de escrita, o valor de uso da rede do relatório soma o tráfego de entrada e o de saída e o compara com o teto de saída, então exagera o quão perto eles estavam de um limite. O mais pesado, o SETNX, usou no máximo cerca de 80% do teto de entrada medido. Mantemos o ≥ neles como uma convenção conservadora. As tabelas completas, as sinalizações e as notas de método estão na página de Desempenho.

Escopo do benchmark

• Build e ajustes. O HotKV foi compilado com -march=native para a CPU do teste, enquanto os outros servidores usaram seus builds de release padrão.
• Configuração de threads. Cada servidor recebeu todos os núcleos da máquina: HotKV --threads 160, Dragonfly com 160 threads proactor, Valkey io-threads 160 e Redis io-threads 128, o máximo dele. O Redis e o Valkey executam comandos em uma única thread e podem alcançar throughput maior com menos threads de E/S, então os valores deles podem estar abaixo do seu melhor. Não executamos clusters nem várias instâncias deles.
• Escopo. Doze comandos, um tamanho de valor, uma profundidade de pipeline, sem TLS e sem persistência. LPOP e RPOP não foram medidos, porque nessas taxas uma leitura destrutiva esvazia, em 10 segundos, qualquer lista que caiba na memória. O relatório registra latência e uso de memória, mas não os comparamos aqui. Os servidores fizeram quantidades de trabalho muito diferentes em cada execução de 10 segundos, então os valores de memória não são comparáveis em condições iguais. Cargas de trabalho mistas não foram medidas.
• Variação. O Redis variou muito entre suas três execuções em vários comandos, até 7,2 vezes entre a execução mais rápida e a mais lenta no HSET, e a mediana esconde isso. Comparado com a execução mais rápida de cada concorrente, em vez da mediana, o HotKV ainda liderou nos 11 comandos.

Redis, Valkey e Dragonfly são marcas comerciais de seus respectivos proprietários. Elas são citadas apenas para identificar o software que medimos, e isso não implica patrocínio, endosso nem afiliação.

O que o HotKV oferece hoje

As principais famílias de comandos incluem strings, listas, conjuntos, hashes, conjuntos ordenados, streams, índices geoespaciais, bitmaps, HyperLogLog, pub/sub e scripts em Lua. Os módulos de IA e os recursos enterprise rodam em planos licenciados. Os preços listam o que cada plano inclui. Consulte a documentação para ver a cobertura atual de comandos. Além do conjunto de comandos do Redis:

• Tags de chaves: rotule chaves com tags arbitrárias e consulte por tag (TAG.SET, TAG.MEMBERS e mais cinco comandos).
• TTL em nanossegundos: NEXPIRE, NTTL e NEXPIREAT definem e leem a expiração em nanossegundos, então os prazos podem ser mais finos que um milissegundo. As chaves expiradas são recuperadas por uma varredura em segundo plano e quando são acessadas.
• Compressão opcional de valores: para valores acima de um limiar de tamanho (512 bytes por padrão), desativada a menos que você a ative.
• Snapshots sem fork: o BGSAVE grava em uma thread em segundo plano, em vez de um processo bifurcado. Um snapshot não é uma cópia de um único ponto no tempo. Cada chave é salva como estava quando o snapshot chegou a ela. A reescrita do arquivo append-only faz fork.
• Métricas do Prometheus: um endpoint HTTP integrado, desativado por padrão e ativado com metrics-port, então nenhum exporter externo é necessário.

O HotKV também tem busca vetorial integrada com índices HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). Nós a medimos contra o Redis 8 em Busca vetorial: HotKV vs. vector sets do Redis 8, de 1 a 100 clientes.

Comece no HotKV Cloud ou fale com as vendas sobre como executar o HotKV nos seus próprios servidores.