Valkey faz 1 ano: como o fork comunitário superou o Redis

• A decisão da Redis Inc de fechar o código-fonte (migração para SSPL) abalou a confiança da comunidade, mas a comunidade de desenvolvedores se uniu em torno do fork Valkey, mantendo um ritmo intenso de inovação e contribuições
• O Redis 8.0 voltou a ser open source, e o fundador Antirez retornou para participar de novos recursos e otimizações, mostrando que os dois lados estão evoluindo rapidamente
• Nos benchmarks mais recentes, o Valkey 8.1.1 apresentou, em um ambiente com 8 vCPUs, desempenho de SET 37% superior ao do Redis 8.0, além de latência p99 menor (o desempenho de GET também foi 16% melhor)
• Com técnicas práticas de tuning, como threads de I/O e pinagem de núcleos, o Valkey alcançou mais de 3x de aumento de throughput em ambientes multithread, além de minimizar a latência
• Também foram compartilhados benchmarks mais próximos de ambientes reais de uso e dicas de tuning, com orientações sobre como interpretar os resultados e aplicá-los em produção

---

O fechamento do código do Redis e o surgimento do Valkey

• Há um ano, a Redis Inc (antiga Garantia Data) deteriorou sua relação de confiança com a comunidade ao alterar sua licença open source (adotando SSPL)
• Como resposta, surgiu o fork aberto Valkey, que se tornou um ativo tecnológico amplamente usado em sistemas distribuídos, cache e processamento de dados em tempo real
• Depois disso, o lado do Redis também tentou recuperar a confiança com o retorno de Antirez (fundador), reforços de desempenho e recursos, e a volta do Redis 8.0 ao modelo open source

Valkey 8.1 vs Redis 8.0: comparação de desempenho

• Benchmark de SET nas mesmas condições: instância AWS c8g.2xl com 8 vCPUs, itens de 1 KB, keyspace de 3 milhões e 500 conexões
  • Valkey 8.1.1: 999.8K RPS (p99 0.8ms)
  • Redis 8.0: 729.4K RPS (p99 0.99ms)
  • O Valkey foi 37% superior em SET e 16% em GET, com p99 30% menor em SET e 60% menor em GET
• Com 6 threads de I/O, o Valkey foi de 239K → 678K RPS (2,8x↑), e o p99 caiu de 1.68ms → 0.93ms (44%↓)
• O Redis também melhorou com threads de I/O: 235K → 563K RPS, p99 de 1.35ms → 0.84ms (40%↓)

O efeito do tuning de multithreading e núcleos

• O efeito das threads de I/O se torna significativo a partir de 3 threads, e o Valkey abre vantagem maior que o Redis a partir de 4 threads
• Ao limitar os núcleos de IRQ (interrupções) a 2 e fixar Redis/Valkey nos 6 núcleos restantes (pinning), há ganho adicional de desempenho
  • Valkey: 832K → 999.8K RPS (pinagem de núcleo/IRQ, com uso de CPU em 80%)
  • A separação entre núcleos de IRQ e da aplicação minimiza a tail latency e melhora a eficiência de cache
  • Também são fornecidos exemplos reais com Docker usando cpuset-cpus, --io-threads e outros parâmetros

Reprodução do benchmark e dicas práticas

• Uso da instância mais recente AWS Graviton4 (c8g.2xlarge) com cluster placement group
• Desempenho máximo obtido com pinagem de núcleos, separação de IRQ e ajuste do número de conexões (na faixa de 400~500)
• Também é necessário ajustar keyspace e tamanho dos itens; valores menores e keyspaces menores aumentam a taxa de acerto no cache L3
• Recomenda-se o uso ativo de ferramentas de benchmark multithread como valkey-benchmark ou rpc-perf (ferramenta em Rust mais próxima do uso real)

  docker run --network="host" --rm --cpuset-cpus="2-7" \  
  valkey/valkey:8.0.1 valkey-benchmark \  
  -h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
  -r 3000000 --threads 6 -d 1024  
  

Limites e cuidados na medição de desempenho

• Os resultados de benchmark podem diferir do ambiente real de produção

  • Workloads reais envolvem fatores combinados, como mistura de SET:GET, variação de carga, meta de TPS e latência de rede
  • Com aumento brusco no número de conexões, também foram observados atraso de fila, queda de throughput e aumento da tail latency
  • Os resultados podem variar bastante conforme a ferramenta/opções de benchmark e a topologia de rede

Principais marcos de crescimento e evolução da comunidade

O projeto Valkey teve um desenvolvimento bastante ativo em diversos aspectos ao longo do último ano

• Em colaboração com muitos desenvolvedores e empresas no GitHub e em outros lugares, houve adição de recursos, correções de bugs e melhorias de segurança
• Também houve investimento em documentação e suporte aos usuários, reduzindo a barreira de entrada para novos usuários
• No processo de governança do projeto, houve ênfase em tomada de decisão transparente e votação da comunidade

Valor técnico e relevância para o setor

O Valkey tem os seguintes pontos fortes

• Pode ser usado por qualquer um sem restrições de licença, o que o torna uma opção atraente para provedores de serviços em nuvem e grandes empresas de serviços web
• Tem alta compatibilidade com o Redis, facilitando a migração
• Como é desenvolvido pela comunidade, consegue refletir diversas necessidades e manter atualizações rápidas e contínuas

Conclusão e implicações

• O Valkey mostrou, em apenas um ano como fork do Redis, resultados que superam o Redis em tecnologia, desempenho e comunidade
• Ferramentas e práticas de tuning como threads de I/O, separação de núcleo/IRQ e ajuste de conexões são fundamentais
• O desempenho não vem automaticamente; a otimização contínua de acordo com sistema, workload e infraestrutura é indispensável
• Em ambientes reais de serviço, é necessária uma abordagem prática: não depender apenas dos números de benchmark, mas testar diretamente diferentes cenários

[ethanhur]

Embora a Redis tenha tomado muitas decisões ruins, é uma pena ver a situação em que o trabalho duro fica com o urso, mas quem recebe o dinheiro é o adestrador.

[kgcrom]

Postado no "Redis User Group" do Facebook
É um material que organiza quais melhorias foram feitas no Valkey 8.
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

Acho que vai ajudar a entender melhor se você ler junto com o conteúdo acima.

[ndrgrd]

Na verdade, não foi tanto que o Valkey tenha feito alguma coisa... foi mais que o outro lado afundou por conta própria...

[GN⁺]

Comentários do Hacker News

• Fico feliz que o ValKey tenha feito avanços legais na área de threading de I/O e que também tenha começado a introduzir algumas das mudanças mais interessantes recentemente. Muito obrigado aos contribuidores do ValKey. Mas acho que este artigo tende a induzir um pouco ao erro. No Redis original, a arquitetura shared nothing era uma filosofia muito importante, e em 2020 fui eu mesmo quem introduziu o threading de I/O. Sem prejudicar a proposta do shared nothing, considerando que as syscalls write(2)/read(2) podem ser muito lentas no momento de retorno do event loop, foi introduzida uma estrutura em que apenas o I/O é processado em paralelo por N threads naquele ponto, em estado de zero contention, e depois retorna imediatamente ao modo single-thread. Agradeço à equipe do ValKey por ter evoluído ainda mais esse sistema. Esse sistema já funcionava há muito tempo, e me incomoda a tendência da mídia de exagerar dados que, na prática, não mudaram tanto. Na realidade, esses recursos interessam muito mais a usuários corporativos ou provedores de nuvem, como Amazon e Google, do que à maioria dos usuários comuns do Redis. A menos que seja inevitável lidar com carga enorme ou muitos usuários ao mesmo tempo, na maior parte dos casos o uso de CPU do Redis é baixo, então nem há necessidade real de ativar isso. Recentemente, ao desenvolver o tipo de dado vector set no Redis, estamos adotando threading como padrão e também permitindo gravações de conjuntos vetoriais via VADD de forma threadizada. Estruturas de dados como HNSW têm, pela primeira vez na história do Redis, tempos constantes gigantescos, então a área de projeto em si muda. No passado, também já havíamos implementado suporte a threads para módulos. Usar threads ou não é uma decisão que depende da situação.
  • É mencionado o fato de que nuances não geram cliques
  • Tenho a sensação de que esse tipo de post crítico aparece na página principal do HN todo mês, e eu sempre quis torcer pelo antirez. Concordo com o ponto técnico, mas acho que esse tipo de crítica muitas vezes está ligado menos a conteúdo concreto e mais ao clássico tall poppy syndrome, de atacar alguém que alcançou grande sucesso. Como não dá para controlar a reação dos outros, talvez seja mais saudável encarar esses posts críticos como um reconhecimento indireto da dimensão das suas conquistas. Também agradeço por estar conectado no LinkedIn. Veja tall poppy syndrome
• Lembro que o antirez anunciou que voltaria a tornar o Redis open source post relacionado. Antigamente o Node.js quase desmoronou por causa do fork do Io.js, mas a comunidade conseguiu recuperá-lo. Fico curioso se o Redis também pode se recuperar assim. Eu usava Redis com frequência antes, mas nos últimos anos não acompanhei muito bem os movimentos da comunidade
  • Da última vez que vi, o Redis ainda exigia CLA (Contributor License Agreement). Isso significa que ele mantém o direito exclusivo de fechar o código novamente a qualquer momento. Se os contribuidores precisam concordar com isso, não há motivo para confiar que não farão a mesma coisa de novo
  • O Redis é distribuído sob AGPL, e o Valkey sob licença BSD (a BSD era a antiga licença do Redis). Ambas são licenças open source oficiais, mas a BSD é muito mais permissiva
  • Sinceramente, 99% dos usuários não se importam com quem é o dono, desde que um armazenamento chave-valor gratuito funcione direito. Do ponto de vista de negócio, o Redis ocupa uma posição peculiar: oferece muitos recursos, mas os usuários reais só usam 5% deles, e não têm interesse em recursos complexos como Sentinel/Streams. Quando tentam monetizar, as opções do usuário são várias: "simplesmente não usar", "migrar para um concorrente", "implementar por conta própria só os recursos realmente necessários" ou "fazer fork da última versão open source e mantê-la internamente para economizar custos". Em comparação com o PostgreSQL, a versão simples do Redis (hashmap + interface de rede) é fácil de implementar por conta própria, então para muitos negócios fazer fork ou construir algo próprio é a melhor escolha
  • Também acho que já é tarde demais. Depois da mudança brusca de política do Redis, para mim o Redis agora é algo em que não dá para confiar, e daqui para frente o Valkey é a opção padrão. Enganado uma vez, não confio de novo
  • Levanta-se a questão de como confiar no Redis depois do que ele fez
• Acho que o Valkey deveria entrar no gerenciador de pacotes padrão das distribuições. Por exemplo, ao tentar instalar no runner do GitHub Actions, é irritante ter que adicionar chave e atualizar a distribuição toda vez
  • Fico curioso sobre em qual distribuição ele não está. Pelo Repology, já está em nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL etc. Só que no Debian é a partir do 13 ou 12+backports
  • Só para referência, no Arch Linux o Valkey já substituiu o Redis
  • Se a primeira tarefa no CI, assim que baixa a imagem do contêiner, é instalar um monte de coisa, a sugestão é que vale mais a pena criar sua própria imagem
• Fico muito feliz de ver essa mudança acontecendo e o Valkey indo bem de forma consistente. Tomara que o Redis desapareça logo
  • Em tom sarcástico, comenta-se que open source é para corporações monopolistas: hyperscalers como a AWS ganham centenas de milhões de dólares com o Redis, enquanto os desenvolvedores e contribuidores de fato não recebem esse benefício. Por isso, startups de banco de dados deveriam começar desde o início com fair source, isto é, uma licença com cláusulas anti-hyperscaler, para que qualquer um possa usar o código à vontade, mas AWS ou Google tenham de pagar caso queiram oferecê-lo como serviço gerenciado. Menciona-se que Redis e Elasticsearch, que começaram com licença ultra permissiva, já têm um destino difícil de reverter
• Ultimamente tem aumentado o número de projetos dotnet que passam para um modelo comercial. Para os desenvolvedores, essas mudanças soam como um rug pull, uma mudança brusca de política que quebra a confiança. Esse clima pode acabar prejudicando também a adoção de outras bibliotecas open source de dotnet
  • No .NET, essa tendência de comercialização não é algo recente; sempre houve essa inclinação de freeware/open-core e negócio andarem juntos
• Ouço falar do Valkey desde o ano passado, e fico feliz de ver que ele ainda está indo bem
• Fico curioso se o Valkey oferece sua própria biblioteca cliente. Hoje uso Redis/Redis Cluster tanto no MemoryStore quanto em ambientes gerenciados diretamente no GCP, e a biblioteca oficial em C foi decepcionante ao usar Redis Cluster+TLS, a ponto de eu ter de usar um cliente não oficial, o hiredis-cluster (https://github.com/Nordix/hiredis-cluster). Também não fiquei muito satisfeito com o Memorystore do GCP. Estou pensando em migrar para Scylla
  • Existe um fork oficial chamado libvalkey, combinando hiredis e hiredis-cluster, mantido pelos mantenedores atuais de hiredis/hiredis-cluster Veja libvalkey
• Agora que o Redis mudou de política, fico curioso se Valkey e Redis poderiam conversar e se reunificar
  • Aponta-se que isso não foi uma volta à licença anterior, e sim uma mudança para AGPL, então não é um retorno de verdade
• Compartilham um ótimo texto explicando o FUD esperado sobre GPL post relacionado
  • Acho que a afirmação do post de que licenças copyleft são mais livres é um argumento um tanto fácil. Quanto mais obrigações existem, menor tende a ser a liberdade, então a discussão sobre qual estilo é mais "livre" parece mais profunda do que isso
• Uso Redis em dezenas de aplicações. Como a AWS oferece Valkey com desconto, experimentei há dois meses e não percebi diferença de desempenho. Mas, do nada, o Valkey travou completamente; na AWS ele ainda aparecia como em execução, mas a conectividade foi totalmente perdida. Não se recuperou por mais de 12 horas, e voltou a acontecer. A AWS investigou por duas semanas e não conseguiu encontrar a causa. Ficou difícil para mim usar Valkey em ambientes mission-critical daqui para frente. Depois troquei pelo Redis com a mesma carga de trabalho, e o problema não ocorreu
  • Provavelmente pode ter sido um problema da AWS. Também tivemos experiência parecida com um cluster RDS Postgres em produção. A resposta de rede travou, recebemos suporte enterprise da AWS, mas no fim tivemos de restaurar backup por conta própria, criar um novo cluster e isso levou 4 horas. Depois disso passamos a evitar serviços encapsulados da AWS e migramos para EC2 comum com replicação, snapshots e replicação para S3
  • Também pode ter sido um problema operacional da AWS; só rodei Redis diretamente, mas pode não ser um problema do próprio Valkey
  • Fico curioso sobre por que não subir uma instância do Valkey diretamente
  • Pergunta qual era o tipo de instância usado, por referência