Redis (e Valkey) em produção: gerenciado vs auto-hospedado em 2026

A pergunta "Redis gerenciado ou auto-hospedado?" virou outra pergunta no fim de março de 2024. Foi quando a empresa por trás do Redis trocou a licença de Apache 2.0 / BSD para uma combinação de RSAL com SSPL — um par de licenças "source available" desenhadas pra impedir que provedores de nuvem oferecessem Redis como serviço sem licenciamento comercial. A reação foi rápida: a Linux Foundation lançou o Valkey como fork direto da última versão BSD, com AWS, Google e Oracle bancando o desenvolvimento. Em paralelo, projetos que já existiam — KeyDB e Dragonfly — passaram a aparecer com mais frequência em benchmarks de empresas que estavam reavaliando a stack.

TL;DR

Em 2026, "Redis em produção" virou uma categoria com quatro implementações disputando o mesmo protocolo: Redis OSS (BSD pré-2024 ou RSAL pós), Valkey (BSD, drop-in pelo fork), KeyDB (multi-thread, fork antigo) e Dragonfly (BSL, reescrita do zero em C++). Auto-hospedar qualquer um dos quatro custa entre R$30 e R$130 por mês em VPS Hetzner. O caminho gerenciado custa de R$75 (ElastiCache micro) até R$1.000/mês (instância de 13 GB), mais Upstash com cobrança serverless variando US$0–100/mês. Pra startup brasileira com MRR abaixo de R$200k, Valkey auto-hospedado num cluster próprio economiza entre R$300 e R$1.500 por mês comparado ao gerenciado, elimina exposição à licença RSAL e mantém compatibilidade total com clientes Redis. Trocar a stack depois de adotar a versão comercial é dor real — começar com a versão amigável a OSS é a aposta com menor custo de saída. Este post compara os quatro produtos, os três caminhos gerenciados (ElastiCache, Upstash, Redis Cloud) e a configuração mínima pra rodar Valkey em produção sem perder noites de sono.

A história curta da mudança de licença

Antes de março de 2024, "Redis" era o cache OSS dominante: BSD, ecossistema gigante, presente em qualquer stack que tivesse cabido a palavra "Rails" ou "Node" no currículo. O fornecedor comercial — Redis Inc, antiga Redis Labs — vivia bem do produto gerenciado e dos módulos pagos (Search, JSON, TimeSeries).

Aí veio o anúncio: a versão 7.4 em diante sairia sob RSAL + SSPL, não mais BSD. Em termos práticos, a mudança visou diretamente AWS, Google e Azure. A leitura interna de quem produz software open source foi outra: "se aconteceu com Redis, pode acontecer com qualquer projeto VC-funded". Foi o terceiro caso recente — depois de Elastic em 2021 e MongoDB em 2018 — em que um projeto que parecia consolidado mudou as regras.

A Linux Foundation foi rápida. Cinco dias após o anúncio, o Valkey foi formado como fork da última versão BSD (7.2.4), com governança independente e backers de peso: AWS, Google Cloud, Oracle, Ericsson, Snap. Em pouco mais de um ano, a AWS já tinha migrado o motor padrão do ElastiCache pra Valkey. O Google Memorystore seguiu. Em 2026, Valkey deixou de ser "fork experimental" pra virar referência crescente — com versões 7.x e 8.x já incorporando otimizações próprias que nem foram ofertadas ao Redis OSS.

A lição operacional pra quem está escolhendo cache hoje: o mainstream se moveu. Não há mais a inércia de "ninguém foi demitido por escolher Redis" — a pergunta na entrevista de arquitetura virou "por que Redis e não Valkey?". E a resposta honesta, na maioria dos casos, é "costume".

Quais são os quatro produtos disputando esse mercado?

Redis OSS

O original. Versões anteriores a 7.4 ainda estão sob BSD e seguem usáveis indefinidamente — ninguém revoga licença retroativa. Versões 7.4 em diante saem sob RSAL/SSPL.

Pros: comunidade ainda enorme, batter-tested em produção há mais de uma década, ecossistema mais rico (módulos, integrações, livros, talks). Quase todo client library testou primeiro contra Redis OSS.

Cons: a RSAL impede oferecer-as-a-service sem licenciamento comercial. Pra quem opera Redis pra uso interno, isso é irrelevante — a restrição é sobre revenda. O risco real é estratégico: se o fornecedor mudou a licença uma vez, pode mudar de novo. Adotar Redis OSS em 2026 significa apostar que a próxima feature crítica vai descer pra ramo aberto, e não ficar no produto comercial.

Valkey

O fork da Linux Foundation. Pegou o código da 7.2.4 BSD e seguiu desenvolvendo. Drop-in replacement no nível de protocolo: nenhum cliente precisa mudar uma linha de código pra trocar Redis por Valkey.

Pros: BSD permanente garantido por governança neutra (não é uma empresa, é fundação). Backers grandes alinham incentivos pra manter o projeto saudável. Paridade técnica com Redis 7.x e velocidade de desenvolvimento crescente.

Cons: a marca ainda está sendo construída — alguns plugins de terceiros e SDKs muito específicos ainda só listam "Redis" no README. Em 2026 isso é cada vez mais cosmético, mas pode aparecer em integrações antigas que precisam de pequena adaptação.

KeyDB

O fork multi-thread. Existe desde 2019, foi adquirido pela Snap em 2022, hoje vive como projeto Snap-Telemetry. A diferença arquitetural é fundamental: Redis OSS e Valkey são single-thread por design (uma thread principal processa todos os comandos). KeyDB roda multi-thread por padrão.

Pros: em CPUs com 4+ núcleos, KeyDB entrega 2 a 3 vezes mais throughput que Redis single-thread no mesmo hardware. API é compatível, então o cliente não muda. Pra workloads CPU-bound com volume alto, é a escolha óbvia.

Cons: comunidade menor, ritmo de adoção de novas features Redis costuma ficar trimestres atrás. Algumas features novas do Redis (Functions, certas extensões) demoram a aparecer no KeyDB.

Dragonfly

A reescrita. Não é fork — é implementação nova em C++ moderno, com hash table desenhada pra cache (não a estrutura genérica do Redis), usando io_uring no Linux pra I/O assíncrono. Compatibilidade no nível do protocolo, não no nível do código.

Pros: claims de 25× throughput em benchmarks específicos (pipelines pesadas em hardware moderno). Memory efficiency real — 2 a 3 vezes mais dados no mesmo RAM que Redis. Sem GIL implícito de single-thread; escala vertical em uma máquina com 32+ cores.

Cons: licença BSL (Business Source License) — fica fechada por 4 anos antes de virar Apache 2.0. É exatamente o mesmo padrão de licença que pegou outros projetos da indústria de orquestração de surpresa, e que tratamos no nosso post sobre por que criamos o HeroCtl. Alguns commands ainda incompatíveis com Redis em casos de borda (scripts Lua complexos, certas operações de cluster).

Qual escolher pra novo projeto em 2026?

A árvore de decisão curta:

• Default sensato: Valkey. BSD permanente, paridade Redis, cliente não precisa mudar, futuro garantido por backers grandes. Não há razão técnica pra preferir Redis OSS pra projeto novo em 2026.
• Performance crítica: Dragonfly, se a aplicação sustenta acima de 100 mil operações por segundo e o time aceita o risco de licença BSL.
• Multi-thread sem reescrita: KeyDB, se o gargalo é CPU em hardware grande e o time prefere não migrar pra Dragonfly.
• Simplicidade extrema (1 VPS, baixo volume): Redis OSS 7.2.4 BSD ainda funciona perfeitamente. Cristalizou como versão estável; vai rodar em qualquer Debian/Alpine pelos próximos cinco anos sem reclamar.
• Migrando de Redis Labs gerenciado: Valkey é drop-in. Zero código mudando. A migração é apenas operacional — replicação, swap de DNS, rollback se necessário.

Gerenciado vs auto-hospedado: a conta sem floreio

Os números abaixo são preço de tabela em maio de 2026, câmbio R$5/USD.

AWS ElastiCache

Cresce em degraus por instância:

• cache.t4g.micro (1 GB): cerca de US$15/mês = R$75/mês
• cache.t4g.small (2 GB): US$30/mês = R$150/mês
• cache.r6g.large (13 GB): cerca de US$200/mês = R$1.000/mês
• cache.r6g.xlarge (26 GB): cerca de US$400/mês = R$2.000/mês

Multi-AZ dobra o preço (réplica em outra zona). Backup automático é incluso. Multi-AZ failover real é o argumento principal — você paga pra não ter que pensar nisso.

Upstash

Cobrança serverless por comando:

• Free tier: 256 MB, 500k commands/dia
• Pay-as-you-go: US$0,2 por 100k commands
• Pra startup com volume médio (10M commands/dia): cerca de US$60/mês = R$300/mês
• Pra app com pico baixo: pode ficar entre US$0 e US$10/mês

A vantagem operacional é única: zero capacidade pré-alocada. Se o app dorme, a conta dorme. Pra Vercel/Cloudflare Workers, é o complemento natural. Pra carga sustentada e previsível, fica mais caro que ElastiCache.

Redis Cloud (oferta direta da Redis Inc)

• Plano Essentials 30MB: free
• Plano Pro 5GB single-region: cerca de US$50/mês = R$250/mês
• Plano Pro 10GB multi-AZ: cerca de US$120/mês = R$600/mês

Inclui módulos comerciais (Search, JSON, TimeSeries) que não existem no Valkey nem no Redis OSS. Se você usa esses módulos, não há alternativa direta — é Redis Cloud ou compra licença comercial e auto-hospeda.

Auto-hospedado em Hetzner

• CPX21 (3 vCPU, 4 GB RAM, 80 GB SSD): €7,99 = R$44/mês. Cabe Valkey de 2 GB com folga.
• CPX31 (4 vCPU, 8 GB RAM, 160 GB SSD): €13,99 = R$78/mês.
• Cluster de 3 CPX21 pra Valkey + Sentinel HA: 3 × €7,99 = €24/mês = R$130/mês.
• Cluster de 3 CPX31 pra dados sérios: €42/mês = R$230/mês.

Pra DigitalOcean, Linode, Vultr, multiplique por aproximadamente 1,5×. Pra AWS EC2, multiplique por 2×. Mas em qualquer caso fica mais barato que o gerenciado equivalente.

Diferença prática

Pra workload de cache de 8 GB com replicação:

• ElastiCache Multi-AZ: ~R$1.000/mês
• Redis Cloud Pro Multi-AZ: ~R$600/mês
• Valkey self-hosted em 3× Hetzner CPX31: R$230/mês
• Valkey single-node em 1× Hetzner CPX31 + backup S3: R$80/mês

Quem escolhe o caminho gerenciado paga 3 a 10 vezes mais pelo mesmo throughput. A diferença é o que você compra com isso: SLA contratual, multi-AZ failover automático, ausência de pager às 3 da manhã. Pra time pequeno, isso pode valer o preço. Pra time que já opera servidores Linux em produção, geralmente não vale.

Stack mínima de Valkey production-grade

Configuração que aguenta produção real sem teatro:

• Container ou systemd service em VPS dedicado. Não compartilha máquina com a aplicação — cache e app concorrem por RAM, e quando dá errado dá errado pros dois ao mesmo tempo.
• maxmemory configurado entre 50 e 70% do RAM disponível. Sobrar memória pro sistema e pros buffers de rede é mais importante que ter os últimos megabytes pra cache.
• maxmemory-policy: allkeys-lru se modo cache puro (jogar fora chaves antigas quando encher). noeviction se modo storage (queue, sessões) — aí prefira erro de write a perder dados silenciosamente.
• AOF persistence se a carga é fila de jobs (Sidekiq, BullMQ, Resque). Sem AOF, um restart perde qualquer job que estava enfileirado mas não processado. RDB é insuficiente nesse cenário porque snapshot é periódico.
• RDB suficiente se a carga é cache puro (Rails cache, Django cache). Se reiniciar perdendo cache só significa "request lento por alguns segundos enquanto reaquece", AOF é overhead desnecessário.
• Replicação async pra standby num segundo nó. Failover manual com swap de DNS interno é aceitável pra muito caso. Failover automático custa Sentinel ou Cluster.
• Backup AOF + RDB pra S3 ou compatível, diariamente. Restic ou rclone resolvem bem.
• Monitoring com redis_exporter exportando pra Prometheus + alertas no Grafana ou similar. Métricas críticas: connected_clients, used_memory, evicted_keys, keyspace_hits/misses, latency_percentiles.

Esse setup roda confortável em CPX21 (R$44/mês) servindo 50k+ ops/s sustentadas pra app brasileira média.

Sentinel ou Cluster?

Pergunta que confunde muito time vindo de Redis pela primeira vez.

Sentinel: 1 master + N réplicas + 3+ processos sentinel monitorando. Failover automático quando o master cai — um sentinel detecta, os sentinels votam, uma réplica vira master, clientes recebem novo endpoint via discovery. Tudo num único shard — todo o dataset cabe num nó.

Cluster: dataset particionado em 16384 slots distribuídos em 3+ masters. Cada master tem suas próprias réplicas. Multi-shard, escala horizontal de capacidade — você pode ter 100 GB total com nenhum nó individual segurando mais de 20 GB.

A regra prática: Sentinel basta até dataset de ~100 GB. Acima disso, Cluster é necessário. Pra maioria das startups brasileiras, Sentinel é a escolha certa por simplicidade — Cluster adiciona complexidade real (chave precisa de hashtag pra operações multi-key, scripts Lua ficam restritos a um slot, alguns clientes têm bugs em modo cluster).

Não use Cluster por status. Use Sentinel até a métrica forçar.

Padrões de Sidekiq, BullMQ e companhia

Use real, não diagrama de marketing:

• Sidekiq Ruby: Redis precisa de AOF. Sem AOF, qualquer crash perde os jobs enfileirados que ainda não foram retirados. Sidekiq Pro adiciona "reliable fetch" que melhora — mas o backstop ainda é AOF.
• BullMQ Node: similar. AOF essential pra durability. BullMQ usa estruturas de dados que dependem de atomicidade transacional do Redis — restart sem AOF pode deixar fila num estado inconsistente.
• Resque Ruby: o pai de todos. AOF necessário pelas mesmas razões.
• Cache puro (Rails.cache, Django cache, Laravel cache): pode rodar sem AOF, RDB suficiente. Perder cache num restart é aceitável.
• Pub/sub puro: nem precisa de persistência. Pub/sub é fire-and-forget por design.

Misturar uso de cache e queue no mesmo Redis funciona — basta configurar AOF (a carga "pior caso" determina). Mas pra workload sério, separar em duas instâncias (uma pra cache sem AOF, outra pra queue com AOF) é mais limpo. Operacionalmente baratíssimo se já há orquestrador rodando.

ElastiCache São Paulo é confiável?

Sim — 99.99% uptime SLA contratual, multi-AZ na região São Paulo (sa-east-1), backup automático, failover testado. Latência da app brasileira pra ElastiCache São Paulo fica em 1-3ms, indistinguível de Redis local pra maioria dos workloads.

O ponto fraco não é confiabilidade técnica, é custo e lock-in. AWS Brazil cobra cerca de 30% mais caro que regiões norte-americanas pelo mesmo recurso. E migrar de ElastiCache pra outro provedor depois envolve dump/restore + cutover coordenado — não é apocalipse, mas é trabalho de fim de semana.

Tabela comparativa: 12 critérios

Quando ainda gerenciado faz sentido

A honestidade é mecanismo de defesa de qualquer recomendação técnica. Há quatro perfis em que pagar pelo gerenciado é a escolha certa:

• Time sem capacidade operacional pra Redis cluster. Se ninguém na empresa sabe debugar um master que não responde mais, ou interpretar latência de fork RDB, ou cuidar de backup AOF — pagar AWS pra fazer isso é racional. Não é desculpa, é divisão de trabalho.
• Compliance que exige fornecedor SOC2/ISO certificado. Auditoria que pede "fornecedor certificado X" não aceita "rodamos Valkey num VPS Hetzner". O caminho é ElastiCache, Redis Cloud ou similar com certificações no contrato.
• Volume que precisa escalar instantâneo. Aplicação que vai de 100 req/s pra 100k req/s em 5 minutos por causa de campanha viral — o caminho serverless do Upstash é onde brilha. Auto-hospedado precisa de capacidade reservada antes; serverless cresce na hora.
• Aplicação totalmente serverless. Se a app roda em Vercel ou Cloudflare Workers e o Redis também precisa ser serverless por modelo de cobrança, Upstash é praticamente a única opção sã. Conectar funções edge a um Redis em VPS implica cold start ruim.

Quando auto-hospedar é óbvio

E quatro perfis em que pagar gerenciado é desperdício:

• Startup com R$10k–R$200k MRR otimizando custo. A diferença entre R$80/mês e R$1.000/mês de cache é 1% do custo total dum SaaS pequeno; também é 11 horas de salário pessoa-hora de dev. Vale a pena fazer a conta.
• Workload predicível. Se o volume de cache cresce 10% ao mês, não há vantagem em escalar serverless. Capacidade reservada em VPS é mais barata e mais previsível.
• Time tem 1+ pessoa confortável com Linux/Docker. Se já tem alguém que opera Postgres, nginx, Docker — Redis/Valkey é mais fácil que qualquer um deles. Curva de aprendizado é dias, não semanas.
• Já existe cluster próprio. Se a empresa roda orquestrador (HeroCtl, Coolify, plataforma similar) com nós sobrando, Valkey vira só mais um job. Custo marginal próximo de zero — você já paga pelos nós.

HeroCtl como infraestrutura pra Valkey

Pra quem opera HeroCtl, rodar Valkey em produção é exercício de configuração curta. Um arquivo de ~30 linhas descreve job com:

• Container Valkey 8.x oficial
• Volume nomeado replicado entre nós (dados sobrevivem a kill -9 de servidor)
• Recursos reservados (RAM e CPU) com limites duros
• Health check no ping Valkey
• Roteamento interno entre serviços (a app fala com valkey.servico.local sem expor porta pra internet)

Backup automatizado AOF + RDB pra S3-compatible está disponível no plano Business — sem montar restic externo, sem cron manual no host. Métricas Valkey saem pelo redis_exporter rodando como sidecar e aparecem no Prometheus interno (já incluído como job do próprio cluster, sem stack externa).

Failover Sentinel é integrado ao plano de controle do orquestrador: se o nó do master Valkey cai, o cluster detecta em torno de 7 segundos e a réplica é promovida. A configuração da app é atualizada via descoberta de serviço — nenhum redeploy manual.

Pra startup com 4 servidores rodando o orquestrador, esse setup substitui ElastiCache Multi-AZ inteiro a custo marginal zero (os servidores já estão lá). A diferença mensal real é o salário-equivalente de uma pessoa, dependendo do tamanho da operação.

Perguntas que recebemos

Valkey é compatível com client libraries Redis? Sim, em 100% dos casos práticos. O protocolo é idêntico — redis-cli, node-redis, ioredis, redis-rb, redis-py, go-redis, todos funcionam sem mudar uma linha. A trocar é apenas o endpoint. Em 2026, várias bibliotecas já anunciam suporte explícito ao Valkey no README, mas isso é cosmético — o protocolo é o mesmo.

Posso migrar de Redis Labs gerenciado pra Valkey self-hosted sem downtime? Sim, com replicação. Configura Valkey como réplica do Redis Labs (REPLICAOF host port), espera sincronizar (alguns minutos a horas dependendo do dataset), promove Valkey a master (REPLICAOF NO ONE), faz cutover de DNS interno, decomissiona Redis Labs depois de período de observação. Janela de erro real é de segundos durante o swap.

Dragonfly vale o risco de BSL? Depende do horizonte da empresa. BSL converte pra Apache 2.0 após 4 anos pelo modelo padrão — então código de hoje será aberto até 2030. O risco é a empresa por trás (DragonflyDB Inc) seguir o caminho da Redis Inc e tornar a conversão menos amigável. Pra workloads que exigem performance que Valkey não entrega (acima de 500k ops/s sustentado), Dragonfly pode ser a escolha certa apesar do risco. Pra resto, Valkey é mais conservador.

Quanto de RAM consome um Redis com 1 GB de dados úteis? Conta pratica: dataset de 1 GB ocupa entre 1,3 e 2 GB reais de RAM (overhead de estrutura, fragmentação, buffers de cliente, replication backlog). Configurar maxmemory em 60% do RAM disponível é regra segura — instância de 4 GB cabe ~2,5 GB de dados úteis com folga.

Sidekiq precisa AOF mesmo? Os docs do Sidekiq dizem que dá pra rodar sem. Os docs falam que tecnicamente roda. Em produção, sem AOF, qualquer restart inesperado perde jobs enfileirados que estavam no buffer. Pra fila de "envio de e-mail bem-vindo", você descobre quando cliente reclama. Pra fila de "cobrança recorrente", descobre quando contador reclama. AOF é barato (incremento de 5-10% de I/O), o custo de não ter é grande.

Cluster vs Sentinel pra app processando 50k jobs/dia? Sentinel. 50k jobs/dia é 0,6 ops/s média — cabem em 100 MB de RAM Redis. Cluster é overkill por ordem de magnitude. Sentinel resolve failover automático com 1 master + 1 réplica + 3 sentinels (3 processos sentinel em VPSs separados, podem coabitar com outras coisas).

ElastiCache São Paulo tem latência boa pra app rodando em São Paulo? Sim, 1-3ms p99 dentro da mesma AZ. O problema não é latência — é custo e lock-in. Latência só vira tema se a app está em outro provedor (Hetzner FSN, DigitalOcean NYC) tentando falar com ElastiCache São Paulo — aí sobe pra 130-200ms e o argumento desaparece.

Como fazer backup de Valkey self-hosted que sobreviva a desastre? Três camadas. Primeira: AOF persistente em disco local (sobrevive a restart). Segunda: snapshot RDB diário copiado pra storage S3-compatible (Wasabi, Backblaze B2, Cloudflare R2 — todos mais baratos que S3 da AWS pra esse caso). Terceira: snapshot semanal copiado pra outro provedor de storage (segunda região, segundo fornecedor). Restic ou rclone fazem o trabalho. Custo total de armazenagem pra backup de Valkey de 4 GB: cerca de US$1/mês.

Fechamento

Em 2026, "Redis em produção" virou pergunta com mais nuance do que tinha em 2023. A licença do produto original mudou, o fork Linux Foundation maturou, alternativas multi-thread estão de pé, a oferta serverless tem caso de uso real. Escolher entre os quatro implementações e os três caminhos gerenciados é exercício honesto — não há resposta única.

A nossa recomendação default pra startup brasileira em 2026: Valkey auto-hospedado num cluster próprio, modo Sentinel, AOF ligado se há queue, monitoring com Prometheus. Custo na faixa de R$80–R$230/mês, contra R$600–R$2.000/mês das alternativas gerenciadas equivalentes. Compatibilidade total com qualquer biblioteca Redis. Sem exposição à licença RSAL. Migração reversível se virar um problema.

Pra colocar essa stack de pé:

curl -sSL https://get.heroctl.com/install.sh | sh

E ler em paralelo: Postgres em produção: gerenciado vs auto-hospedado (mesma análise pro banco de dados) e Quanto custa hospedar SaaS brasileiro em 2026 (a conta consolidada de toda a stack).