Valkey: a melhor alternativa open-source de substituição direta para o Redis
Em março de 2024, a Redis Inc. passou da sua licença BSD permissiva para a RSALv2/SSPLv1, criando uma exposição real de conformidade para equipas de engenharia comerciais.
Em resposta, a comunidade OSS e de utilizadores criou quase imediatamente uma bifurcação de código do Redis para uma nova opção chamada Valkey. Lançado no mesmo mês sob a Linux Foundation, o Valkey oferece uma verdadeira substituição direta que evita a carga legal introduzida pelo Redis.
Substitua o Redis sem reconstruir as suas aplicações
A resposta das comunidades às alterações de licença do Redis foi procurar opções rápidas, coordenadas e com bons recursos, principalmente uma bifurcação de código das comunidades. O Valkey não é uma bifurcação de código de protesto com pouco suporte. O Valkey beneficia de um apoio institucional substancial e de desenvolvimento ativo – por isso, é uma alternativa totalmente licenciada sob a BSD com total compatibilidade com a base de código Redis que a maioria das equipas já utiliza.
Valkey: Tranquilidade integrada no projeto e no serviço
![[object Object]](https://assets.ovhcloud.com/1fiLCdLm2rnpzzL64g7Ebupwy_sN2JmNTk4MzJkMDY1NjMw/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_96bcf0ea.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fihA7kvoqCdjbpFh8CSqrAFg_sODM3OGYwNzczYjJhNGI5/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_a2fe1080.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fi4ELnwoChAbqnnwm3zvgAv5_sODJhOTlmMGI0OTUzYWJl/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_f9914d17.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiz8uqm8kwozpmrpt2nCdg5F_sNzRjNjI0Y2U4ZDlmOWQ0/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_fe1d1635.svg){kind=small}
Por que razão os programadores procuram uma alternativa ao Redis em 2026
Explicação da alteração da licença do Redis em 2024
Durante a maior parte da sua existência, o Redis foi distribuído sob a licença BSD de 3 Cláusulas, uma das licenças de código aberto mais permissivas. Podia utilizar, modificar e criar produtos comerciais com base no Redis sem restrições. Isso mudou a 20 de março de 2024, quando a Redis Inc. anunciou que o Redis 7.4 e todos os futuros lançamentos de funcionalidades passariam para um modelo de licença dupla: RSALv2 (Redis Source Available License v2) e SSPLv1 (Server Side Public License). Nenhuma das licenças é aprovada pela Open Source Initiative (OSI), e ambas impõem restrições explícitas sobre a forma como o software pode ser utilizado em ambientes comerciais e de cloud.
Por que razão a SSPL cria um risco de conformidade para produtos comerciais
A SSPL foi originalmente escrita pela MongoDB para impedir que os fornecedores de cloud oferecessem serviços de base de dados geridos sem contribuírem de volta. O problema central para as equipas de produtos comerciais é a Secção 13: se a sua aplicação for disponibilizada como um serviço e depender de software licenciado sob a SSPL, poderá ser obrigado a disponibilizar o código-fonte de toda a sua pilha de serviços, incluindo componentes proprietários que desenvolveu.
Para a maioria das equipas de engenharia, essa obrigação é um obstáculo ao desenvolver funcionalidades e alternativas. Mesmo quando o aconselhamento jurídico determina que o risco é baixo na prática, a incerteza por si só cria fricção com o aprovisionamento, revisões de segurança e contratos de clientes empresariais. A RSALv2 agrava isto ao proibir explicitamente a utilização em produtos ou funcionalidades concorrentes, conferindo à Redis Inc. uma ampla margem sobre o que constitui concorrência... deixando, mais uma vez, os utilizadores do Redis expostos a um campo minado de desafios legais – desafios que são facilmente evitados utilizando código regido por uma licença aprovada pela OSI.
Permanecer no Redis 7.2: a dívida de segurança oculta
O último lançamento de armazenamento em cache do Redis sob a BSD foi a versão 7.2. Algumas equipas optam por ficar nessa versão em vez de aceitar os novos termos de licença. É, indiscutivelmente, uma decisão pragmática a curto prazo que acarreta um custo a longo prazo. O Redis 7.2 já não recebe patches de segurança de pesquisa ou correções de erros da Redis Inc., o que significa que quaisquer CVE descobertas após a alteração da licença permanecem por resolver nessa ramificação. Para equipas que executam o armazenamento em cache do Redis 7.2 num ambiente de produção, que lidam com dados sensíveis ou que operam ao abrigo de quadros como o NIS2 ou SOC 2, este não é um risco teórico. Manter o Redis 7.2 cria uma lacuna de conformidade ativa que aumenta a cada mês que passa.
Porque é que a AGPLv3 para o Redis 8.0 não é uma terceira opção
Com o lançamento do Redis 8.0 em 2025, a Redis Inc. fez outra alteração de licenciamento, desta vez para a AGPLv3, que é aprovada pela OSI. É um genuíno avanço em termos de legitimidade de código aberto e aborda uma das principais críticas feitas à alteração de 2024. No entanto, a AGPLv3 é uma licença copyleft forte e introduz as suas próprias complicações para as equipas comerciais.
Qualquer software que interaja com um componente licenciado sob a AGPLv3 através de uma rede pode desencadear a obrigação de disponibilizar o código-fonte desse software sob a mesma licença. Para produtos SaaS proprietários, isto continua a ser uma restrição significativa para alternativas. Várias vozes proeminentes na indústria, incluindo colaboradores do projeto Valkey, notaram que a AGPLv3 (embora mais baseada em princípios do que a SSPL) ainda coloca o Redis numa categoria diferente das alternativas de código aberto verdadeiramente permissivas.
Preservar o comportamento da aplicação e controlar a localização dos dados
Os layouts de vários nós também podem preservar padrões de resiliência familiares. A compatibilidade ainda requer testes. Os módulos, o comportamento específico da versão e combinações de comandos invulgares podem produzir uma resposta diferente. O design de armazenamento, as definições do cliente e a topologia também podem afetar a estabilidade ou o débito. Nenhuma migração deve assumir que todos os casos extremos serão executados mais rapidamente ou se comportarão de forma idêntica. A licença do Valkey, aprovada pela OSI, oferece às equipas comerciais uma alternativa de código aberto duradoura ao Redis, sem vincular a arquitetura da aplicação a termos restritivos.
A escolha da implementação acrescenta então uma dimensão operacional. Uma oferta europeia gerida pode combinar processamento thread, posicionamento resiliente de nós e alojamento de dados controlado. Esta abordagem apoia a soberania de dados europeia, mantendo a localização, o acesso e o tratamento contratual visíveis, ao mesmo tempo que reduz a administração de rotina da plataforma.
O DragonflyDB lidera no débito de nó único bruto em alguns testes, mas essa vantagem diminui significativamente em configurações de cluster. A paridade de funcionalidades com o Redis 7.2 está completa e o roteiro do Valkey adicionou desde então melhorias de multithreads e ganhos de eficiência de memória que, em algumas cargas de trabalho, o colocam à frente da versão da qual derivou.
Outras tecnologias podem adequar-se a requisitos especializados, como pesquisa vetorial ou cargas de trabalho sem servidor intermitentes. A investigação pode incluir material técnico encontrado através do Google, discussões na comunidade e documentação de fornecedores, mas a documentação primária e os testes controlados devem ter maior peso. Compare cada alternativa por alteração de aplicação, maturidade operacional, suporte disponível, governação e esforço total de migração. A tecnologia apropriada é aquela que cumpre os requisitos medidos com licenciamento e risco operacional aceitáveis.
Adapte o modelo operacional aos seus requisitos
Valkey Gerido
As Bases de Dados Geridas para o Valkey adequam-se a empresas que pretendem operações simples e custos de infraestrutura previsíveis. A OVHcloud gere a alta disponibilidade, manutenção, monitorização e cópias de segurança, reduzindo o trabalho interno necessário para executar um serviço resiliente. A largura de banda e IOPS incluídos também tornam a orçamentação mais clara. Esta é uma predefinição prática quando as equipas da plataforma precisam do Valkey sem terem de assumir todas as tarefas operacionais.
Valkey autogerido
A autogestão proporciona controlo sobre as versões de software, topologia, definições de segurança e localização da implementação. Pode adequar-se a empresas com requisitos específicos ou operações de base de dados estabelecidas. As desvantagens são igualmente reais: a equipa interna é responsável pelas atualizações, cópias de segurança, observabilidade, testes de falha e resposta a incidentes. Os recursos da comunidade ajudam, mas não substituem o suporte de produção responsável ou a capacidade operacional.
KeyDB
O KeyDB pode adequar-se a equipas que investigam a execução multithread para cargas de trabalho de dados em memória específicas e objetivos de latência. Avalie a compatibilidade, a atividade de lançamento, a saúde do projeto e o suporte disponível antes de se comprometer. Avalie a aplicação real em vez de assumir que uma funcionalidade arquitetural irá melhorar todos os padrões de pedido. A informação associada a um fundador ou a uma declaração inicial do projeto também deve ser verificada tendo em conta a documentação atual.
Alternativas especializadas
Os serviços sem servidor podem reduzir o planeamento de capacidade para cargas de trabalho intermitentes, enquanto as bases de dados vetoriais suportam a pesquisa de semelhança e outros modelos de dados especializados. Software alternativo em memória pode visar necessidades restritas de débito ou persistência. Estas ferramentas podem resolver problemas definidos, mas não são necessariamente escolhas de substituição direta. Tenha em conta as alterações à aplicação, a movimentação de dados, a responsabilidade operacional e o custo a longo prazo antes de os selecionar em detrimento do Valkey.
Escolha um caminho de migração que se adeque ao tempo de inatividade
Desligue a sua instância Redis para garantir a consistência, copie o ficheiro para o seu diretório de dados Valkey, inicie o Valkey e está concluído. O tempo total de migração é proporcional ao tamanho do conjunto de dados, não à complexidade da aplicação. Para ambientes de produção onde o tempo de inatividade não é aceitável, a replicação em tempo real é o caminho mais seguro. O Valkey pode ser configurado como uma réplica de uma instância Redis 7.2 em execução utilizando o comando padrão REPLICAOF.
Assim que a réplica estiver totalmente sincronizada, atualize o string de suporte de ligação da sua aplicação para se direcionar para o Valkey, promova-o a primário e desative a instância Redis. Como ambos os sistemas utilizam o mesmo protocolo de replicação, este processo é simples e bem testado em produção por equipas em todos os principais fornecedores de cloud.
![[object Object]](https://assets.ovhcloud.com/1fiX676v6wSp4t82zXEm6hhry_sNzAzOTNmMTIyZWVkYzg0/555a10a6-71ae-4d77-959e-b2a8dc0e9831_ima_c8d0550b.png)
Construa uma estrutura de prontidão para migração de quatro partes
1. Compatibilidade da aplicação
Crie um inventário de cada comando, biblioteca cliente e versão de protocolo em utilização. Registe funcionalidades RESP3, scripts Lua, transações, padrões pub/sub, dependências JSON ou de módulos e comportamento de tempo limite específico da aplicação. Um núcleo compatível não prova que todas as extensões se comportam da mesma forma. Compare o ambiente atual com a versão alvo e teste pedidos representativos. Inclua o tratamento de falhas, a gestão de pools de ligações e a lógica de repetição. Se uma aplicação depender de tecnologia fornecida por um plugin externo, verifique o seu estado de manutenção separadamente. Este inventário transforma a compatibilidade geral em evidência baseada em requisitos específicos.
2. Proteja a integridade dos dados
Meça o conjunto de dados antes da migração, incluindo contagens de chaves, distribuição de expiração, tamanhos de objetos e consumo máximo de memória. O destino necessita de memória suficiente para o funcionamento normal, replicação e sobrecarga temporária durante a sincronização ou persistência. Reveja as definições de snapshot e de anexação apenas, em vez de as copiar sem análise. Após a transferência, compare as contagens de chaves, valores de amostras e comportamento de expiração. As verificações ao nível da aplicação podem revelar problemas que os totais brutos não detetam, como sessões mal formadas ou estado de fila incompleto. Partilhe os critérios de aceitação com os proprietários dos serviços antes da transição, para que todos utilizem a mesma definição de um conjunto de dados válido.
3. Mapeie a topologia de destino
Documente se a plataforma atual é autónoma, replicada ou distribuída por um cluster. Registe cada nó, rota de rede, regra de segurança, dependência de DNS e localização física. Este mapa ajuda as equipas a selecionar um esquema de destino que reflita as necessidades de resiliência, em vez de reproduzir escolhas históricas. Os testes de conectividade devem abranger a aplicação, os sistemas de monitorização e as ferramentas administrativas. Para uma carga de trabalho distribuída, verifique o processamento de slots, a colocação de réplicas e o comportamento durante a perda de nós. Os requisitos de localização de dados também podem determinar quais as regiões ou zonas de disponibilidade aceitáveis.
4. Controle a transição
Estabeleça linhas de base de latência, taxa de erro e recursos antes de mover o tráfego. Defina os limiares de monitorização, os critérios de reversão e os responsáveis pela tomada de decisão enquanto o serviço estiver estável. Isto evita que as equipas debatam o comportamento aceitável durante um incidente. Transfira o tráfego por fases sempre que a arquitetura o permita. Comece com cargas de trabalho internas ou de baixo risco, observe os erros dos clientes e compare os resultados, depois aumente a quota. Mantenha a origem recuperável até que a validação esteja concluída. Uma transição segura depende de evidências medidas, de uma responsabilidade clara e de uma via de reversão, e não apenas de alegações de compatibilidade.
Porquê escolher as Bases de Dados Geridas da OVHcloud para Valkey
Uma das frustrações persistentes com as bases de dados geridas na cloud é a imprevisibilidade da faturação. Pense em custos que disparam com carga porque a largura de banda, IOPS e armazenamento de cópias de segurança são medidos separadamente. O modelo de preços da OVHcloud agrupa estes custos numa tarifa mensal fixa. A largura de banda, as operações de E/S e as cópias de segurança automatizadas estão incluídas, pelo que o custo que vê no aprovisionamento é o custo que paga em produção. Para as equipas financeiras e de aprovisionamento em empresas em fase de expansão que gerem orçamentos de infraestrutura apertados, isto torna o planeamento de capacidade significativamente mais simples.
