HotKV vs Dragonfly

Uma alternativa ao Dragonfly, medida lado a lado

Os dois servidores são multithread e falam o protocolo Redis, então uma alternativa ao Dragonfly™ precisa justificar a troca nos detalhes. Como as threads compartilham dados, como os dados são persistidos e o que vem integrado ao servidor. A HotKV Ltd mediu os dois em uma única máquina de 160 vCPUs com a mesma carga, e publicou todos os números, incluindo o que deu empate.

Obter acesso antecipado Veja as medições

Dragonfly

um shard por thread

MGET a b c

HotKV

um único armazenamento compartilhado

MGET a b c
Uma ilustração, não uma medição. O Dragonfly dá a cada thread sua própria fatia do espaço de chaves, então um comando cujas chaves caem em várias fatias é coordenado entre threads. O HotKV roda todas as threads em um único armazenamento compartilhado.

Esta alternativa ao Dragonfly, rodando como instância única em uma máquina de 160 vCPUs, liderou 11 de 12 comandos contra o Dragonfly 2.0.2, com 2.0x a 4.4x a vazão. O HotKV foi compilado a partir do código-fonte para essa CPU. O Dragonfly 2.0.2 rodou como sua build padrão. A diferença é menor em máquinas pequenas.

Substituição direta

O que permanece igual com esta alternativa ao Dragonfly

O HotKV implementa o protocolo de rede do Redis. Migrar do Dragonfly costuma ser uma troca de host e credenciais. Verifique a referência de comandos para qualquer coisa fora do conjunto central.

Mesmo protocolo

RESP2 e RESP3 com negociação HELLO. O HotKV informa a versão 8.4.0 do Redis aos clientes, então as bibliotecas escolhem seus recursos com base nela. Strings de conexão, pipelines, pub/sub e transações funcionam como funcionam hoje.

Mesmos clientes e ferramentas

Bibliotecas cliente do Redis e do Valkey, redis-cli, redis-cli --cluster e ferramentas gráficas se conectam ao HotKV sem mudanças de código para os comandos centrais.

Mesmos comandos centrais

300 comandos centrais, scripts Lua e bibliotecas de funções, além das famílias de comandos próprias do HotKV quando você quiser.

o cliente que você já usa
$ redis-cli -h <your-hotkv-host> -p 6379 --tls --user app --askpass
> HELLO 3
1# "server" => "hotkv"
2# "version" => "8.4.0"
3# "proto" => (integer) 3
   ... (mais quatro campos)
> SET session:4821 "same protocol, every core"
OK
> GET session:4821
"same protocol, every core"
> TAG.SET session:4821 tenant:acme   # um comando do HotKV, quando você quiser
(integer) 1

Os argumentos a favor de uma alternativa ao Dragonfly

Por que as equipes procuram uma alternativa ao Dragonfly

Propriedades documentadas do Dragonfly que levam as equipes a procurar uma alternativa ao Dragonfly, verificadas em 21 de outubro de 2026.

01

Shards sem compartilhamento

O Dragonfly divide o espaço de chaves em um shard por thread. Um comando que toca chaves em vários shards, como MSET ou MGET, é coordenado entre threads. O HotKV roda todas as threads em um único armazenamento compartilhado. Essa diferença é o coração desta alternativa ao Dragonfly.

02

Sem arquivo append-only

O Dragonfly persiste com snapshots pontuais (point-in-time). Sua documentação afirma que ele atualmente não suporta AOF. Uma alternativa ao Dragonfly com um arquivo append-only fecha essa lacuna. O HotKV oferece snapshots e AOF.

03

Código-fonte disponível sob BSL 1.1

O Dragonfly é licenciado sob a Business Source License 1.1. Sua concessão permite o uso dentro do seu próprio produto ou serviço. Ela não permite o uso como produto ou serviço de armazenamento de dados em memória, nem oferecer o Dragonfly como serviço hospedado que concorra com a DragonflyDB. O código converte para Apache 2.0 na sua data de mudança, 1 de novembro de 2030 para o texto atual da licença. O HotKV é software comercial sob seus próprios termos de licença.

04

A busca vetorial é integrada, os caches de IA não

O Dragonfly tem busca vetorial. Cache de prompts, cache semântico, memória de agentes e rastreamento de custos de LLM não fazem parte do servidor.

Medido, não alegado

Esta alternativa ao Dragonfly, medida. HotKV vs Dragonfly 2.0.2 em uma única máquina

A HotKV Ltd rodou o HotKV e o Dragonfly 2.0.2 um de cada vez, como instâncias únicas, na mesma máquina de 160 vCPUs. Cada um recebeu a mesma carga e todos os núcleos. A HotKV Ltd publicou todos os números com o método e os dados brutos.

11 de 12
comandos em que o HotKV mediu a maior vazão contra o Dragonfly
2.0x a 4.4x
Vazão do HotKV como múltiplo da do Dragonfly, nos 11 comandos em que liderou (MGET a INCR)
PING
O Dragonfly mediu 0,6% mais alto, dentro do limite dos geradores de carga, então conta como empate

A HotKV Ltd compilou o HotKV a partir do código-fonte para esta CPU. O Dragonfly rodou como sua build de lançamento padrão. Ambos rodaram como instâncias únicas. As contagens de threads seguiram a configuração documentada de todos os núcleos de cada produto e não foram ajustadas por produto. A diferença é menor em máquinas com poucos núcleos.

SET3.4x
HotKV
50.5M*
Dragonfly
15.0M
GET2.7x
HotKV
36.6M*
Dragonfly
13.4M
MGET2.0x
HotKV
4.6M*
Dragonfly
2.3M
SETNX3.8x
HotKV
55.3M*
Dragonfly
14.4M
APPEND2.8x
HotKV
25.1M
Dragonfly
8.9M
INCR4.4x
HotKV
90.8M
Dragonfly
20.6M
LPUSH3.0x
HotKV
31.6M
Dragonfly
10.6M
RPUSH4.0x
HotKV
43.8M
Dragonfly
11.0M
SADD4.2x
HotKV
50.6M*
Dragonfly
12.0M
HSET3.0x
HotKV
29.0M*
Dragonfly
9.8M
MSET3.8x
HotKV
11.3M
Dragonfly
2.9M
PING0.99x
HotKV
125.2M†
Dragonfly
126.0M

Operações por segundo, mediana de 3 execuções de 10 segundos. Cada par de barras é escalado pelo servidor mais rápido naquele comando.

* Limitado pela rede: a rede da instância definiu este resultado, então o limite do próprio servidor é maior.

† Limitado pelo gerador de carga: as máquinas geradoras de carga rodaram acima de 85% de CPU, então este é o teto delas, não o do servidor.

Azure D160alds_v7 (AMD EPYC 9V45 (Turin), 160 vCPUs), medido em 9 de outubro de 2026. Valores de 256 bytes, profundidade de pipeline 30, 5.000.000 de chaves pré-carregadas lidas uniformemente ao acaso. Três máquinas geradoras de carga dedicadas. Cada servidor rodou sozinho como instância única com persistência desligada. Cada um recebeu todos os núcleos (Redis com 128 threads de I/O, seu máximo). A HotKV Ltd compilou o HotKV a partir do código-fonte para esta CPU e rodou o Dragonfly como sua build de lançamento padrão. Método completo e resultados · Harness e dados brutos

Lado a lado

Esta alternativa ao Dragonfly e o Dragonfly, recurso por recurso

FuncionalidadeHotKVDragonfly
Execução de comandosMultithread. Todos os núcleos leem, analisam e executam comandos em um único armazenamento compartilhadoMultithread, um shard do espaço de chaves por thread (sem compartilhamento)
ProtocoloRESP2 e RESP3, com negociação HELLO. Informa a versão 8.4.0 do Redis aos clientesRESP2 e RESP3
LinguagemC++20, construído do zeroC++
LicençaComercial (HotKV Cloud, ou uma licença on-premise)BSL 1.1
PersistênciaSnapshots e AOFApenas snapshots, sem AOF
Snapshots sem forkSim. Uma thread em segundo plano grava o snapshot, sem processo filho bifurcadoSim
Busca por similaridade vetorialIntegrada (HNSW, VSIM.*), todos os planosIntegrada
Cache de prompts e cache semântico para LLMIntegrado (PCACHE.*, SCACHE.*), plano Performance e superiores no HotKV CloudNão
Memória de agentes de IAIntegrada (AMEM.*), plano Performance e superiores no HotKV CloudNão
Rastreamento de tokens e custos de LLMIntegrado (LLMBUDGET.*, LLMSTATS.*), plano Performance e superiores no HotKV CloudNão
Endpoint PrometheusIntegrado. O próprio servidor serve /metrics assim que metrics-port é definido (on-premise)Integrado
Histogramas de latência por comandoPor comando, integrado (LATENCY HISTOGRAM)Flag opcional de rastreamento de latência. LATENCY HISTOGRAM consta como não suportado
Marcação de chavesSim (TAG.*)Não
TTL em nanossegundosSim (NEXPIRE, NTTL)Não. TTLs em milissegundos
Plataformas do servidorLinux (x86_64 e ARM64)Linux (x86_64 e ARM64)
ImplantaçãoHotKV Cloud (Google Cloud, 42 regiões) ou on-premise sob licençaAutogerenciado ou Dragonfly Cloud

Para ser justo

Onde o Dragonfly está à frente desta alternativa ao Dragonfly, ou é simplesmente diferente

Esta página de alternativa ao Dragonfly só é útil quando diz esta parte também.

  • No PING, o Dragonfly mediu 0,6% acima do HotKV. Os geradores de carga estavam acima de 80% de CPU para ambos, então a HotKV Ltd conta isso como empate. Ele aparece na tabela de qualquer forma.
  • Os snapshots do Dragonfly são sem fork, como os do HotKV, e ele serve métricas Prometheus por conta própria.
  • O Dragonfly é gratuito para auto-hospedar dentro do seu próprio produto sob a BSL 1.1, e o Dragonfly Cloud é um serviço gerenciado maduro. Esta alternativa ao Dragonfly, o HotKV Cloud, está em acesso antecipado.

Fazendo a mudança

Do Dragonfly para esta alternativa ao Dragonfly em quatro etapas

O que mudar para uma alternativa ao Dragonfly envolve na prática.

  1. 1

    Crie uma instância

    Escolha uma região e um plano no console do HotKV Cloud. A instância é uma máquina própria, provisionada, atualizada e monitorada para você.

  2. 2

    Aponte seus clientes para ela

    Mantenha a biblioteca cliente que você já usa. Troque o host, a porta e as credenciais do Dragonfly pelos da instância HotKV. TLS e autenticação por senha estão ativos desde o início, com usuários ACL disponíveis. Uma alternativa ao Dragonfly que fala o mesmo protocolo não exige mudanças no cliente para os comandos centrais.

  3. 3

    Mova os dados

    Use as ferramentas que você já conhece. DUMP e RESTORE, MIGRATE, ou um replay das suas escritas funcionam, porque o HotKV implementa esses comandos.

  4. 4

    Ative o que faltava

    Busca vetorial e marcação de chaves são comandos centrais em todos os planos. Caches de prompts e semânticos, memória de agentes e rastreamento de custos de LLM são comandos do mesmo servidor no plano Performance e superiores. Sem módulo, sidecar ou segundo serviço. É isso que uma alternativa ao Dragonfly deve acrescentar.

Perguntas

Perguntas sobre esta alternativa ao Dragonfly

Os dois são multithread. O que há de diferente nesta alternativa ao Dragonfly?

O Dragonfly dá a cada thread seu próprio shard do espaço de chaves, então um comando cujas chaves caem em vários shards é coordenado entre threads. O HotKV deixa todas as threads trabalharem em um único armazenamento compartilhado, então comandos multi-chave e comandos de chave única seguem o mesmo caminho.

Como os dois se compararam no benchmark?

Em uma Azure D160alds_v7, rodando como instâncias únicas, o HotKV registrou a maior vazão mediana em 11 dos 12 comandos contra o Dragonfly 2.0.2. O múltiplo foi de pelo menos 2 vezes no MGET a pelo menos 4,4 vezes no INCR. O PING foi um empate dentro do limite dos geradores de carga. Todos os números, o método e os dados brutos estão publicados.

O HotKV tem AOF?

Sim. O HotKV persiste com snapshots e um arquivo append-only. A documentação do Dragonfly afirma que ele atualmente não suporta AOF.

Posso migrar do Dragonfly sem mudar meu código?

Os dois servidores falam RESP2 e RESP3, então as mesmas bibliotecas cliente se conectam a esta alternativa ao Dragonfly para os comandos centrais. Mova os dados com DUMP e RESTORE, MIGRATE, ou um replay das suas escritas. Verifique a referência de comandos para qualquer coisa fora do conjunto central.

Coloque esta alternativa ao Dragonfly à prova com os clientes que você já tem

O HotKV Cloud está abrindo em ondas. Cada instância desta alternativa ao Dragonfly é uma máquina dedicada com o motor multithread. As famílias de comandos de IA vêm com os planos Performance e Scale.

Obter acesso antecipado Preços