Redis e o custo da ambição

• O Redis chegou ao ponto de avaliar um grande PR para um array type em 2026, transformando-se de um simples servidor de estruturas de dados em um produto que tenta abranger várias áreas
• O Redis inicial, fiel ao nome Remote Dictionary Server, conquistou rapidamente espaço na stack web com um dicionário em memória veloz, comandos enxutos e um protocolo simples
• Nos últimos 10 anos, o Redis se expandiu com Streams, JSON, search, graph, time-series, Redis-Raft, vector sets e mais, reforçando uma orientação cada vez mais forte para database
• O inchaço de funcionalidades enfraqueceu a simplicidade e consistência que eram pontos fortes do Redis e aumentou as integrações meio amadurecidas em áreas que exigem ferramentas especializadas
• O Valkey, em vez de correr atrás de recursos chamativos, foca em desempenho multithread, eficiência de memória e confiabilidade de cluster, mirando a base de usuários do Redis de 2011

---

A identidade que o Redis perdeu

• O Redis chegou ao ponto de avaliar um grande PR para adicionar um array type em 2026, algo que simboliza sua transformação de um simples servidor de estruturas de dados em um produto que tenta cobrir várias áreas
• O array type PR, de antirez, parte do problema de que Hash, List e Stream têm pontos fortes em acesso aleatório, append/trim e eventos append-only, respectivamente, mas não conseguem oferecer ao mesmo tempo acesso intermediário e visibilidade por intervalo como um array
• O Redis já tem recursos que podem ser usados como array, como arrays JSON, time-series e sorted-set, mas a própria direção de adicionar mais um novo tipo mostra bem o caráter de expansão funcional
• O problema central é o enfraquecimento da simplicidade que levou o Redis ao sucesso no início, junto com seu protocolo claro, comandos enxutos e ortogonais e consistência conceitual

As mudanças dos últimos 10 anos

• Licença e direção da empresa

  • A Redis Inc abandonou a licença BSD em 2024 e depois recuou para um esquema de tripla licença que inclui AGPLv3 como única opção OSI
  • Graças à AGPLv3, a Redis Inc pode dizer que é open source, mas trata-se de uma licença de natureza muito diferente da BSD
  • A empresa apoiada por VC por trás do Redis era originalmente a Garantia Data, um serviço de hospedagem em nuvem NoSQL; depois migrou para hospedagem de Redis, adotou um nome ligado ao ecossistema Redis e trouxe antirez para ganhar legitimidade
  • O processo, alguns anos depois, de receber os direitos da marca acabou servindo de base para a posterior mudança de licença, e textos e comentários antigos sobre isso hoje parecem datados de uma forma previsível

• Expansão de funcionalidades e posicionamento do produto

  • O Redis começou com um pequeno conjunto de tipos de dados úteis, mas com o tempo passou a incluir estruturas de dados exóticas, sistemas stateful complexos como Streams e até módulos com caráter semiproprietário dependendo da versão
  • Em 2026, o posicionamento do Redis na landing page mudou para “The Real-Time Context Engine for AI Apps”
  • Na landing page aparecem juntos os botões “Try Redis for Free” e “Get a Demo”, como também dá para ver nesta captura de tela

• Orientação para banco de dados em escala web

  • Recursos como Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex® e Redis-on-Flash® mostram que o Redis vem se orientando para ser um “banco de dados em escala web”

• Mudanças no protocolo e cache no lado do cliente

  • O RESP3 rompe em vários pontos com o modelo de requisição/resposta que era a premissa básica do RESP2, sendo avaliado como algo próximo ao padrão de fracasso do segundo sistema descrito por Brooks
  • O Redis era amplamente usado originalmente como cache, mas agora chegou ao ponto de precisar até de um novo protocolo para oferecer suporte a cache no lado do cliente

Por que o Redis inicial funcionou tão bem

• Contexto da época

  • Por volta de 2011, entre desenvolvedores web, eram fortes tendências como NoSQL, “web scale”, Bigtable, Dynamo, Ruby on Rails, REST e JSON
  • O Redis combinou muito bem com esse clima e virou, quase da noite para o dia, uma ferramenta presente em muitas stacks
  • No fim de 2011, a apresentação do Redis o descrevia como advanced key-value store e data structure server, sem usar a palavra “database”

• Um dicionário remoto melhor que o Memcached

  • O memcached era uma infraestrutura essencial que rodava discretamente em muitos servidores web e era usado com frequência não só para cache, mas também para usos temporários como locks, contadores e rate limit
  • Na época, o Redis era percebido como algo próximo de “memcached but way better”, e o próprio nome Remote Dictionary Server reforçava essa natureza de dicionário rápido em memória
  • Em vez de apenas blobs de bytes, o Redis oferecia estruturas de dados bem escolhidas como linked-list, hash-table, set e sorted-set, ampliando muito os usos práticos e improvisados

• Um protocolo simples e expressivo na medida certa

  • O protocolo wire do Redis era simples o bastante para ser entendido e implementado em uma hora, mas poderoso o suficiente para representar vários tipos de dados
  • As bibliotecas cliente eram simples e elegantes de implementar, e o próprio protocolo era considerado natural
  • O tutorial write your own Redis para criar diretamente o protocolo e um servidor simples de Redis continua sendo um texto popular escrito há cerca de 10 anos

• Single-thread, orientado a eventos e em memória

  • O design single-thread do Redis garantia a atomicidade de todas as operações, reduzindo muito a complexidade e tornando o comportamento fácil de raciocinar
  • Para que o single-thread funcionasse, o servidor precisava ser implementado com non-blocking I/O, e as operações sobre os dados também tinham de ser muito rápidas
  • Essa combinação tornou possível, com uma única thread, um key/value store veloz capaz de atender muitos clientes

• Estruturas de dados adequadas para aplicações web

  • Strings com tempo de expiração eram ideais para cache, listas para filas e hashes para dados estruturados
  • Casos de uso como locks, contadores, rate limiting, liveness, monitoramento e leaderboards também podiam ser montados facilmente só com os tipos de dados embutidos

A ambição de virar um banco de dados

• A adoção do Redis cresceu rapidamente e foi um grande sucesso, mas em algum momento a ambição do projeto passou a ser a de se tornar uma database
• Alguns recursos de fato foram úteis; o BZPOPMIN, adicionado no Redis 5.0, permitiu fazer blocking pop em sorted-set usado como priority queue, aumentando sua utilidade prática
• Em contrapartida, recursos como ACL pareciam destoar do que era o Redis, e no geral se destacava o desejo de transformar o Redis em tudo para todos
• A adição de recursos no Redis se conecta ao padrão de seguir os “últimos modismos” sobre os quais desenvolvedores discutiam no Hacker News ao longo dos últimos 10 anos
  • Se o MongoDB armazena JSON, então o Redis também deveria virar um document database
  • Se o ElasticSearch oferece full-text search, então o Redis também deveria virar um search engine
  • Quando graph database ganhou atenção, o Redis também tentou virar um graph database, mas isso acabou levando ao RedisGraph EOL
  • Quando o Kafka ganhou destaque, o Redis também quis virar uma event streaming platform
  • À medida que ZooKeeper e bancos de dados com forte consistência se tornaram importantes, surgiu o Redis-Raft, e a análise do Jepsen, de Aphyr, é tratada como leitura quase obrigatória
  • Quando o InfluxDB ganhou atenção, o Redis também quis virar um time series database
  • E, para não ficar para trás na onda da IA, passaram a ser necessários recursos ligados a IA como vector sets

O preço da expansão funcional

• O primeiro problema é que isso enfraquece justamente os fatores que fizeram do Redis uma ferramenta essencial em praticamente toda stack
  • O Redis era simples, seus comandos eram ortogonais e estreitamente definidos, o protocolo era limpo e a ferramenta era conceitualmente consistente
• O segundo problema é que quem quer integrar seriamente full-text search, processamento de event streams, key/value com forte consistência, time-series e armazenamento vetorial não quer módulos meio amadurecidos herdando as limitações do Redis, e sim ferramentas especializadas
• A alta disponibilidade do Redis é complexa, sua persistência envolve trade-offs sutis, e a carga do protocolo e a fragmentação de clientes também viram obstáculos reais
• A posição aqui é que o Redis não é uma ferramenta para substituir o Postgres, e sistemas como ElasticSearch e RabbitMQ ainda precisam continuar como pilares próprios
• A análise inicial de Aphyr sobre a implementação do Redis-Raft afirma ter encontrado 21 problemas
  • Longos períodos de indisponibilidade em clusters saudáveis
  • 8 crashes
  • 3 stale reads
  • 1 aborted read
  • 5 bugs que levavam à perda de atualizações já commitadas
  • 1 loop infinito
  • 2 problemas capazes de enviar respostas logicamente corrompidas ao cliente
  • A avaliação foi de que a primeira versão testada, 1b3fbf6, era praticamente inutilizável
• O Redis como cache e servidor de estruturas de dados e o Redis que tenta ser “Redis the etcd” ou outro banco de dados especializado são propostas fundamentalmente diferentes, e essa distância é o problema central

O mesmo padrão revelado pelo Disque

• Em 2015, antirez anunciou o Disque e disse na época que ele não partiu de casos de uso reais, mas foi projetado em “astronaut mode” ao observar pessoas usando Redis como fila de mensagens e olhando para outros message queues
• Projetos criados como desafio pessoal ou exercício de aprendizado, sem um caso de uso real, ainda podem ser excelentes, mas outra questão é se conseguem continuar resolvendo a longa cauda de problemas difíceis que aparece quando os usuários aumentam
• Entrega de mensagens com alta disponibilidade é um problema genuinamente difícil, e independentemente de qual lado do teorema CAP se tente otimizar, não há como escapar dos trade-offs e dos problemas difíceis
• Em 2015, já existiam muitos message brokers maduros, e o motivo de as pessoas usarem Redis como broker era que elas já usavam Redis e ele era simples o bastante
• O que se precisava não era de um novo message broker, nem de um Redis se tornando um message broker mais complexo
• O Disque virou praticamente abandonware logo após o anúncio e, mesmo com 8K stars no GitHub, ficou largado
• Depois foi reescrito como módulo do Redis, mas esse projeto também está abandonado há 7 ou 8 anos

A direção diferente mostrada pelo Valkey

• As forças que moveram a trajetória do Redis podem ser reunidas em três ambições: a ambição do desenvolvedor de resolver problemas complexos, a ambição de virar tudo para todos e a ambição de seus donos de extrair o máximo de receita antes de perder espaço para AWS e GCP
• A ambição em si não é o problema, mas passa a ser quando leva à perda das razões do sucesso
• A existência e a adoção do Valkey são apresentadas como o julgamento final de um mercado mais amplo sobre essa dinâmica
• Em vez de perseguir funcionalidades ou bullet points de tabela comparativa, o Valkey investe em trabalhos menos chamativos como desempenho multithread, eficiência de memória, confiabilidade de cluster e melhoria de throughput
• Os benchmarks de desempenho do Valkey são impressionantes e miram diretamente os 80% dos usuários de Redis para quem o que o Redis oferecia em 2011 já era suficiente
• No mundo do Valkey, a conclusão é que não há necessidade de um novo array type

[GN⁺]

Comentários no Lobste.rs

• Tendo participado do crescimento de software de código aberto em escala considerável, da criação de uma empresa, de alcançar centenas de milhões de dólares em receita, IPO e até uma venda de bilhões de dólares, além de já ter feito mudança de licença saindo de OSS, a posição do Redis como um “motor de contexto em tempo real para apps de IA” parece, em termos de direção, fazer sentido
  Na compra de software existem os usuários reais e os tomadores de decisão técnica (TDM), e a landing page do Redis parece um site voltado aos TDMs com orçamento, mais do que aos desenvolvedores que de fato usam o produto. Muitos TDMs preferem decisões “pelas quais ninguém será demitido”, no estilo “ninguém foi demitido por escolher a IBM”, e se Gartner ou McKinsey enfatizam estratégia de IA e gestão de contexto, então “Context Engine para apps de IA” vira uma justificativa de compra defensável
  Na HashiCorp também tentaram separar terraform.io para o pessoal operacional e hashicorp.com para TDMs, e isso funcionou até certo ponto, mas tinha limites. É um problema difícil para empresas de OSS guiadas por desenvolvedores
  Os botões “usar Redis grátis” e “solicitar demo” também não soam estranhos do ponto de vista de TDM. TDMs não querem assumir a responsabilidade por decisões técnicas e, na verdade, preferem pagar e comprar software; por isso, o gratuito é rebaixado a algo mais próximo de um trial, enquanto o call to action de falar com uma pessoa fica em destaque
  A liderança da Redis Inc. aparentemente concluiu que é mais importante atrair TDMs do que desenvolvedores/operadores; sem dados internos é difícil dizer se isso está certo ou errado, mas não parece ter sido uma estratégia sem intenção
  Continuar adicionando funcionalidades também faz sentido porque o custo de expandir uma ferramenta existente é muito menor do que o custo de introduzir uma nova. Mesmo sem motivação comercial, linguagens de programação muitas vezes acabam virando o menor denominador comum de todos os recursos, em vez de preservar sua identidade central; em empresas comerciais, o “land and expand” atua com força. Fecha-se o primeiro contrato com um recurso principal e depois vende-se uma expansão com recursos adicionais medianos, porque o departamento de compras processa muito mais facilmente a ampliação de um contrato existente do que um contrato novo
  A afirmação de que “clientes sérios vão querer produtos realmente especializados para busca, event streams, KV com consistência forte, séries temporais e armazenamento vetorial” também é muito controversa. Mesmo olhando apenas para dados de empresas de software aberto ao mercado, clientes frequentemente escolhem opções piores por motivos não técnicos
  Também é difícil afirmar com certeza que o Valkey é o veredito final do mercado. O Valkey está indo muito melhor do que um fork médio (https://redmonk.com/sogrady/2026/04/06/valkey-at-two/), mas a empresa Redis também, de fora, parece estar se sustentando bem. Se olharmos para empresas como ElasticSearch ou MongoDB, que mudaram a licença e ainda assim tiveram forks sem sofrer grande impacto em sua avaliação de mercado, outras conclusões também são possíveis. Na bolha dos desenvolvedores isso pode parecer diferente, mas se receita é o indicador final e atrasado, também dá para perguntar: “isso realmente importou tanto assim?”
  Não estou tentando defender interesses comerciais, só compartilhando a perspectiva de quem viu o outro lado. É parecido com o fato de que, diante do mesmo produto agrícola, quem faz compras e quem cultiva a terra fazem perguntas e têm objetivos completamente diferentes

  • O “porquê” do ponto de vista comercial foi bem explicado, e acrescenta contexto ao fato de que o Redis não existe num vácuo puramente de software, que os excêntricos de OSS não são o alvo e que tomadores de decisão têm critérios diferentes dos engenheiros de sistemas
    Ainda assim, essa lógica parece partir do pressuposto de que o objetivo de todo mundo é dinheiro. A ambição de ganhar uma quantidade enorme de dinheiro com Redis é apenas um tipo específico de ambição, e pela atitude que o antirez mostrou no texto, ele não parece alguém que se importasse tanto assim com dinheiro
    Há um contraexemplo em SQLite. Ele não fala em receita de milhões nem em venda de bilhões; concentra-se silenciosamente em entregar algo bem definido. O SQLite não perdeu aquilo que o tornou o banco de dados embarcado mais popular, e no mundo dos bancos maiores o mesmo vale para o Postgres. Dá para trazer contraexemplos desse outro mundo tanto quanto do mundo do dinheiro e dos interesses comerciais
    No caso do Redis, “já usamos AWS/GCP, então vamos usar algo parecido com Redis deles” parece ser o resultado natural da expansão horizontal. O caminho mais “IBM” é escolher um provedor de nuvem e usar o Redis desse provedor, e hoje em dia isso acaba sendo Valkey
    O fato de as pessoas escolherem opções piores não é polêmico, é um fato, e a expansão do Redis nesse modo é justamente um exemplo da ambição e deriva que eu queria destacar
  • Trabalhei na Redis Labs, então eu estava quase literalmente na posição de advogado do diabo dos desenvolvedores. Quando saí, não exerci as opções já adquiridas, e moro longe o bastante do Vale do Silício para poder falar sem me preocupar tanto em queimar pontes demais
    Antigamente, redis.com era o site para TDMs e redis.io era para desenvolvedores, mas depois que a Redis Labs tomou para si o redis.io que pertencia ao antirez, eles o estragaram a ponto de ficar difícil até achar o link de download, e agora as duas URLs levam a sites voltados a TDM. Até hoje é difícil encontrar facilmente o link de download do Redis, a ponto de eu querer dizer para você procurar por conta própria
    O problema central é que a Redis Labs sempre contratou liderança de marketing muito mal. CMOs e VPs chegavam, torravam o máximo possível da boa vontade em pouco tempo e, seis meses depois, partiam para a “próxima aventura”. Quando viram que o tráfego de redis.io era muito maior que o de redis.com, estragaram o redis.io esperando que quem não encontrasse o link de download clicasse em “try free”; isso parece um exemplo clássico de ganância por clique de curto prazo
    Vender recursos adicionais também ajuda a se diferenciar dos concorrentes em listas de checklist. Isso vale especialmente quando é difícil competir em preço, e a AWS podia empacotar descontos agressivos de nuvem com o ElastiCache; o pior concorrente de todos era o Redis open source gratuito
    O Valkey está recebendo muito mais dinheiro do que um fork comum. Por exemplo, o ex-responsável por relações com desenvolvedores da Redis Labs agora está na AWS trabalhando com Valkey
    Ainda assim, acho injusta a avaliação de que o Valkey só faz “trabalho sem glamour”. O Redis já é multithread há bastante tempo; o plano de controle ainda é single-thread, mas o I/O é multithread, então o trabalho do Valkey não é tão novo quanto o autor parece pensar
    O Valkey é, de forma explícita, uma operação para que empresas de nuvem como a AWS possam continuar vendendo Redis sem pagar dinheiro a ninguém. Qualquer outra justificativa é só ferramenta de marketing para convencer as pessoas a deixá-los continuar fazendo o que querem fazer; se concluírem que quebrar a compatibilidade com Redis é comercialmente vantajoso, eles vão fazer isso. Eu apostaria com alguma confiança que talvez ambos os lados já tenham feito isso em certa medida, embora eu não tenha acompanhado o bastante para afirmar com certeza
    Se você quer um fork de Redis realmente focado em fazer o “trabalho sem glamour” mantendo a simplicidade, existe o redict
    Mesmo assim, acho que o tempo do Redis está chegando ao fim. No estranho cenário comercial atual, cada fork manca de um jeito diferente. Até o redict, o mais virtuoso deles, parece não ter interesse real em empurrar o Redis adiante da mesma forma que o antirez fazia quando tocava o projeto original quase como um ditador benevolente. Não quero dizer que seja ruim quando um software fica “pronto”, mas acho que ainda existem áreas interessantes e inexploradas para o Redis, e duvido que os forks comerciais criem esse tipo de ecossistema. Claro, posso estar subestimando o valor de Arrays e de aplicações ligadas a IA, então mantenho a mente aberta
    Olhando para trás, é impressionante como a Redis Labs conseguiu estragar tudo isso tão profundamente, e ainda bem que já passou tempo suficiente para eu sentir menos raiva
  • Parece que as empresas querem pegar o máximo possível sem pagar. Talvez seja por isso que Redis, MongoDB e HashiCorp acabaram mudando a licença

• Na empresa, estamos criando um sistema de fila de tarefas mais justo com scripts Lua, e o Redis parece muito estranho. Meu modelo mental sempre foi “um armazenamento simples de chave-valor”, mas acabo aprendendo sobre todo tipo de funcionalidade, como a execução de scripts Lua dentro de um lock global
  Só que a documentação está num site brilhante e chamativo, e não explica as coisas com clareza. Alguns parâmetros de configuração, por exemplo, só são explicados dentro do arquivo de exemplo de configuração
  Eu sei que o Redis funciona bem e todo mundo diz isso, mas a experiência de aprender os recursos do Redis é bem desconfortável. Parece que alguém criou um programa realmente excelente e esqueceu a documentação excelente que um programa bom normalmente deveria ter
  É uma reclamação meio estranha. O Redis parece funcionar extremamente bem, e eu gosto de documentação no estilo da do Postgres, que explica “tudo”

  • Fico curioso se a documentação de um produto menos orientado a TDM é mais fácil de entender: https://valkey.io/topics/programmability/
    Muitos projetos open source também sabem muito bem que têm documentação fraca, então parece que esse experimento não tem apenas a variável dos chefes engravatados
  • O Redis costumava ter documentação de todo tipo e, felizmente, a Wayback Machine permite desfazer os estragos feitos pela Redis Labs. Talvez você encontre aqui o que procura: https://web.archive.org/web/20190725152042/…
    O redict também parece ter uma boa documentação: https://redict.io/docs/scripting/