Redis (y Valkey) en producción: gestionado vs auto-hospedado en 2026

La pregunta "¿Redis gestionado o auto-hospedado?" se volvió otra pregunta a finales de marzo de 2024. Fue cuando la empresa detrás de Redis cambió la licencia de Apache 2.0 / BSD a una combinación de RSAL con SSPL — un par de licencias "source available" diseñadas para impedir que proveedores de nube ofrecieran Redis como servicio sin licenciamiento comercial. La reacción fue rápida: la Linux Foundation lanzó Valkey como fork directo de la última versión BSD, con AWS, Google y Oracle financiando el desarrollo. En paralelo, proyectos que ya existían — KeyDB y Dragonfly — pasaron a aparecer con más frecuencia en benchmarks de empresas que estaban reevaluando el stack.

TL;DR

En 2026, "Redis en producción" se volvió una categoría con cuatro implementaciones disputando el mismo protocolo: Redis OSS (BSD pre-2024 o RSAL post), Valkey (BSD, drop-in por el fork), KeyDB (multi-thread, fork antiguo) y Dragonfly (BSL, reescritura desde cero en C++). Auto-hospedar cualquiera de los cuatro cuesta entre R$30 y R$130 al mes en VPS Hetzner. El camino gestionado cuesta desde R$75 (ElastiCache micro) hasta R$1.000/mes (instancia de 13 GB), más Upstash con cobro serverless variando US$0–100/mes. Para startup con MRR por debajo de R$200k, Valkey auto-hospedado en un cluster propio ahorra entre R$300 y R$1.500 al mes comparado al gestionado, elimina exposición a la licencia RSAL y mantiene compatibilidad total con clientes Redis. Cambiar el stack después de adoptar la versión comercial es dolor real — empezar con la versión amigable a OSS es la apuesta con menor coste de salida. Este post compara los cuatro productos, los tres caminos gestionados (ElastiCache, Upstash, Redis Cloud) y la configuración mínima para correr Valkey en producción sin perder noches de sueño.

La historia corta del cambio de licencia

Antes de marzo de 2024, "Redis" era el cache OSS dominante: BSD, ecosistema gigante, presente en cualquier stack que hubiera cabido la palabra "Rails" o "Node" en el currículum. El proveedor comercial — Redis Inc, antigua Redis Labs — vivía bien del producto gestionado y de los módulos de pago (Search, JSON, TimeSeries).

Llegó el anuncio: la versión 7.4 en adelante saldría bajo RSAL + SSPL, no más BSD. En términos prácticos, el cambio apuntó directamente a AWS, Google y Azure. La lectura interna de quien produce software open source fue otra: "si pasó con Redis, puede pasar con cualquier proyecto VC-funded". Fue el tercer caso reciente — después de Elastic en 2021 y MongoDB en 2018 — en que un proyecto que parecía consolidado cambió las reglas.

La Linux Foundation fue rápida. Cinco días después del anuncio, Valkey fue formado como fork de la última versión BSD (7.2.4), con governanza independiente y backers de peso: AWS, Google Cloud, Oracle, Ericsson, Snap. En poco más de un año, AWS ya había migrado el motor por defecto de ElastiCache a Valkey. Google Memorystore siguió. En 2026, Valkey dejó de ser "fork experimental" para volverse referencia creciente — con versiones 7.x y 8.x ya incorporando optimizaciones propias que ni siquiera fueron ofrecidas a Redis OSS.

La lección operacional para quien está eligiendo cache hoy: el mainstream se movió. Ya no hay la inercia de "nadie fue despedido por elegir Redis" — la pregunta en la entrevista de arquitectura se volvió "¿por qué Redis y no Valkey?". Y la respuesta honesta, en la mayoría de los casos, es "costumbre".

¿Cuáles son los cuatro productos disputando ese mercado?

Redis OSS

El original. Versiones anteriores a 7.4 aún están bajo BSD y siguen usables indefinidamente — nadie revoca licencia retroactivamente. Versiones 7.4 en adelante salen bajo RSAL/SSPL.

Pros: comunidad aún enorme, batter-tested en producción desde hace más de una década, ecosistema más rico (módulos, integraciones, libros, talks). Casi toda client library testeó primero contra Redis OSS.

Cons: la RSAL impide ofrecer-as-a-service sin licenciamiento comercial. Para quien opera Redis para uso interno, eso es irrelevante — la restricción es sobre reventa. El riesgo real es estratégico: si el proveedor cambió la licencia una vez, puede cambiar de nuevo. Adoptar Redis OSS en 2026 significa apostar que la próxima feature crítica va a bajar a rama abierta, y no quedarse en el producto comercial.

Valkey

El fork de la Linux Foundation. Tomó el código de la 7.2.4 BSD y siguió desarrollando. Drop-in replacement a nivel de protocolo: ningún cliente necesita cambiar una línea de código para cambiar Redis por Valkey.

Pros: BSD permanente garantizado por governanza neutra (no es una empresa, es fundación). Backers grandes alinean incentivos para mantener el proyecto saludable. Paridad técnica con Redis 7.x y velocidad de desarrollo creciente.

Cons: la marca aún se está construyendo — algunos plugins de terceros y SDKs muy específicos aún solo listan "Redis" en el README. En 2026 eso es cada vez más cosmético, pero puede aparecer en integraciones antiguas que necesitan pequeña adaptación.

KeyDB

El fork multi-thread. Existe desde 2019, fue adquirido por Snap en 2022, hoy vive como proyecto Snap-Telemetry. La diferencia arquitectural es fundamental: Redis OSS y Valkey son single-thread por diseño (un thread principal procesa todos los comandos). KeyDB corre multi-thread por defecto.

Pros: en CPUs con 4+ cores, KeyDB entrega 2 a 3 veces más throughput que Redis single-thread en el mismo hardware. API es compatible, así que el cliente no cambia. Para workloads CPU-bound con volumen alto, es la elección obvia.

Cons: comunidad menor, ritmo de adopción de nuevas features Redis suele quedar trimestres atrás. Algunas features nuevas de Redis (Functions, ciertas extensiones) tardan en aparecer en KeyDB.

Dragonfly

La reescritura. No es fork — es implementación nueva en C++ moderno, con hash table diseñada para cache (no la estructura genérica de Redis), usando io_uring en Linux para I/O asíncrono. Compatibilidad a nivel del protocolo, no a nivel del código.

Pros: claims de 25× throughput en benchmarks específicos (pipelines pesados en hardware moderno). Memory efficiency real — 2 a 3 veces más datos en la misma RAM que Redis. Sin GIL implícito de single-thread; escala vertical en una máquina con 32+ cores.

Cons: licencia BSL (Business Source License) — queda cerrada por 4 años antes de volverse Apache 2.0. Es exactamente el mismo patrón de licencia que pegó a otros proyectos de la industria de orquestación por sorpresa, y que tratamos en nuestro post sobre por qué creamos HeroCtl. Algunos commands aún incompatibles con Redis en casos de borde (scripts Lua complejos, ciertas operaciones de cluster).

¿Cuál elegir para nuevo proyecto en 2026?

El árbol de decisión corto:

• Default sensato: Valkey. BSD permanente, paridad Redis, cliente no necesita cambiar, futuro garantizado por backers grandes. No hay razón técnica para preferir Redis OSS para proyecto nuevo en 2026.
• Performance crítica: Dragonfly, si la aplicación sostiene por encima de 100 mil operaciones por segundo y el equipo acepta el riesgo de licencia BSL.
• Multi-thread sin reescritura: KeyDB, si el cuello de botella es CPU en hardware grande y el equipo prefiere no migrar a Dragonfly.
• Simplicidad extrema (1 VPS, bajo volumen): Redis OSS 7.2.4 BSD aún funciona perfectamente. Cristalizó como versión estable; va a correr en cualquier Debian/Alpine los próximos cinco años sin quejarse.
• Migrando de Redis Labs gestionado: Valkey es drop-in. Cero código cambiando. La migración es solo operacional — replicación, swap de DNS, rollback si necesario.

Gestionado vs auto-hospedado: la cuenta sin adornos

Los números abajo son precio de tabla en mayo de 2026, cambio R$5/USD.

AWS ElastiCache

Crece en escalones por instancia:

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

Multi-AZ duplica el precio (réplica en otra zona). Backup automático está incluido. Multi-AZ failover real es el argumento principal — pagas para no tener que pensar en eso.

Upstash

Cobro serverless por comando:

• Free tier: 256 MB, 500k commands/día
• Pay-as-you-go: US$0,2 por 100k commands
• Para startup con volumen medio (10M commands/día): cerca de US$60/mes = R$300/mes
• Para app con pico bajo: puede quedar entre US$0 y US$10/mes

La ventaja operacional es única: cero capacidad pre-asignada. Si la app duerme, la cuenta duerme. Para Vercel/Cloudflare Workers, es el complemento natural. Para carga sostenida y predecible, queda más caro que ElastiCache.

Redis Cloud (oferta directa de Redis Inc)

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

Incluye módulos comerciales (Search, JSON, TimeSeries) que no existen en Valkey ni en Redis OSS. Si usas esos módulos, no hay alternativa directa — es Redis Cloud o compras licencia comercial y auto-hospedas.

Auto-hospedado en Hetzner

• CPX21 (3 vCPU, 4 GB RAM, 80 GB SSD): €7,99 = R$44/mes. Cabe Valkey de 2 GB con holgura.
• CPX31 (4 vCPU, 8 GB RAM, 160 GB SSD): €13,99 = R$78/mes.
• Cluster de 3 CPX21 para Valkey + Sentinel HA: 3 × €7,99 = €24/mes = R$130/mes.
• Cluster de 3 CPX31 para datos serios: €42/mes = R$230/mes.

Para DigitalOcean, Linode, Vultr, multiplica por aproximadamente 1,5×. Para AWS EC2, multiplica por 2×. Pero en cualquier caso queda más barato que el gestionado equivalente.

Diferencia práctica

Para workload de cache de 8 GB con replicación:

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

Quien elige el camino gestionado paga 3 a 10 veces más por el mismo throughput. La diferencia es lo que compras con eso: SLA contractual, multi-AZ failover automático, ausencia de pager a las 3 de la mañana. Para equipo pequeño, eso puede valer el precio. Para equipo que ya opera servidores Linux en producción, generalmente no vale la pena.

Stack mínimo de Valkey production-grade

Configuración que aguanta producción real sin teatro:

• Container o systemd service en VPS dedicado. No comparte máquina con la aplicación — cache y app compiten por RAM, y cuando da error da error para los dos al mismo tiempo.
• maxmemory configurado entre 50 y 70% de la RAM disponible. Sobrar memoria para el sistema y para los buffers de red es más importante que tener los últimos megabytes para cache.
• maxmemory-policy: allkeys-lru si modo cache puro (tirar claves antiguas cuando llene). noeviction si modo storage (queue, sesiones) — ahí prefiere error de write a perder datos silenciosamente.
• AOF persistence si la carga es cola de jobs (Sidekiq, BullMQ, Resque). Sin AOF, un restart pierde cualquier job que estaba enfilado pero no procesado. RDB es insuficiente en ese escenario porque snapshot es periódico.
• RDB suficiente si la carga es cache puro (Rails cache, Django cache). Si reiniciar perdiendo cache solo significa "request lento por algunos segundos mientras recalienta", AOF es overhead innecesario.
• Replicación async para standby en un segundo nodo. Failover manual con swap de DNS interno es aceptable para mucho caso. Failover automático cuesta Sentinel o Cluster.
• Backup AOF + RDB para S3 o compatible, diariamente. Restic o rclone resuelven bien.
• Monitoring con redis_exporter exportando para Prometheus + alertas en Grafana o similar. Métricas críticas: connected_clients, used_memory, evicted_keys, keyspace_hits/misses, latency_percentiles.

Ese setup corre cómodo en CPX21 (R$44/mes) sirviendo 50k+ ops/s sostenidas para app medio.

¿Sentinel o Cluster?

Pregunta que confunde a mucho equipo viniendo de Redis por primera vez.

Sentinel: 1 master + N réplicas + 3+ procesos sentinel monitoreando. Failover automático cuando el master cae — un sentinel detecta, los sentinels votan, una réplica se vuelve master, clientes reciben nuevo endpoint vía discovery. Todo en un único shard — todo el dataset cabe en un nodo.

Cluster: dataset particionado en 16384 slots distribuidos en 3+ masters. Cada master tiene sus propias réplicas. Multi-shard, escala horizontal de capacidad — puedes tener 100 GB total con ningún nodo individual sosteniendo más de 20 GB.

La regla práctica: Sentinel basta hasta dataset de ~100 GB. Por encima, Cluster es necesario. Para mayoría de las startups, Sentinel es la elección correcta por simplicidad — Cluster añade complejidad real (clave necesita hashtag para operaciones multi-key, scripts Lua quedan restringidos a un slot, algunos clientes tienen bugs en modo cluster).

No uses Cluster por status. Usa Sentinel hasta que la métrica fuerce.

Patrones de Sidekiq, BullMQ y compañía

Uso real, no diagrama de marketing:

• Sidekiq Ruby: Redis necesita AOF. Sin AOF, cualquier crash pierde los jobs enfilados que aún no fueron retirados. Sidekiq Pro añade "reliable fetch" que mejora — pero el backstop sigue siendo AOF.
• BullMQ Node: similar. AOF essential para durability. BullMQ usa estructuras de datos que dependen de atomicidad transaccional de Redis — restart sin AOF puede dejar cola en estado inconsistente.
• Resque Ruby: el padre de todos. AOF necesario por las mismas razones.
• Cache puro (Rails.cache, Django cache, Laravel cache): puede correr sin AOF, RDB suficiente. Perder cache en un restart es aceptable.
• Pub/sub puro: ni siquiera necesita persistencia. Pub/sub es fire-and-forget por diseño.

Mezclar uso de cache y queue en el mismo Redis funciona — basta configurar AOF (la carga "peor caso" determina). Pero para workload serio, separar en dos instancias (una para cache sin AOF, otra para queue con AOF) es más limpio. Operacionalmente baratísimo si ya hay orquestador corriendo.

¿ElastiCache São Paulo es confiable?

Sí — 99.99% uptime SLA contractual, multi-AZ en la región São Paulo (sa-east-1), backup automático, failover testeado. Latencia de la app desde São Paulo a ElastiCache São Paulo queda en 1-3ms, indistinguible de Redis local para mayoría de los workloads.

El punto débil no es confiabilidad técnica, es coste y lock-in. AWS Brazil cobra cerca de 30% más caro que regiones norteamericanas por el mismo recurso. Y migrar de ElastiCache a otro proveedor después implica dump/restore + cutover coordinado — no es apocalipsis, pero es trabajo de fin de semana.

Tabla comparativa: 12 criterios

Cuándo aún gestionado tiene sentido

La honestidad es mecanismo de defensa de cualquier recomendación técnica. Hay cuatro perfiles en que pagar por gestionado es la elección correcta:

• Equipo sin capacidad operacional para Redis cluster. Si nadie en la empresa sabe debugar un master que ya no responde, o interpretar latencia de fork RDB, o cuidar de backup AOF — pagar AWS para hacer eso es racional. No es excusa, es división de trabajo.
• Compliance que exige proveedor SOC2/ISO certificado. Auditoría que pide "proveedor certificado X" no acepta "corremos Valkey en un VPS Hetzner". El camino es ElastiCache, Redis Cloud o similar con certificaciones en el contrato.
• Volumen que necesita escalar instantáneo. Aplicación que va de 100 req/s a 100k req/s en 5 minutos por una campaña viral — el camino serverless de Upstash es donde brilla. Auto-hospedado necesita capacidad reservada antes; serverless crece al instante.
• Aplicación totalmente serverless. Si la app corre en Vercel o Cloudflare Workers y Redis también necesita ser serverless por modelo de cobro, Upstash es prácticamente la única opción sana. Conectar funciones edge a un Redis en VPS implica cold start malo.

Cuándo auto-hospedar es obvio

Y cuatro perfiles en que pagar gestionado es desperdicio:

• Startup con R$10k–R$200k MRR optimizando coste. La diferencia entre R$80/mes y R$1.000/mes de cache es 1% del coste total de un SaaS pequeño; también son 11 horas de salario persona-hora de dev. Vale la pena hacer la cuenta.
• Workload predecible. Si el volumen de cache crece 10% al mes, no hay ventaja en escalar serverless. Capacidad reservada en VPS es más barata y más predecible.
• Equipo tiene 1+ persona cómoda con Linux/Docker. Si ya tiene a alguien que opera Postgres, nginx, Docker — Redis/Valkey es más fácil que cualquiera de ellos. Curva de aprendizaje son días, no semanas.
• Ya existe cluster propio. Si la empresa corre orquestador (HeroCtl, Coolify, plataforma similar) con nodos sobrando, Valkey se vuelve solo otro job. Coste marginal cerca de cero — ya pagas por los nodos.

HeroCtl como infraestructura para Valkey

Para quien opera HeroCtl, correr Valkey en producción es ejercicio de configuración corta. Un archivo de ~30 líneas describe job con:

• Container Valkey 8.x oficial
• Volumen nombrado replicado entre nodos (datos sobreviven a kill -9 de servidor)
• Recursos reservados (RAM y CPU) con límites duros
• Health check en el ping Valkey
• Enrutamiento interno entre servicios (la app habla con valkey.servicio.local sin exponer puerto a internet)

Backup automatizado AOF + RDB para S3-compatible está disponible en el plan Business — sin montar restic externo, sin cron manual en el host. Métricas Valkey salen por el redis_exporter corriendo como sidecar y aparecen en el Prometheus interno (ya incluido como job del propio cluster, sin stack externo).

Failover Sentinel está integrado al plano de control del orquestador: si el nodo del master Valkey cae, el cluster detecta en torno de 7 segundos y la réplica es promovida. La configuración de la app se actualiza vía descubrimiento de servicio — ningún redeploy manual.

Para startup con 4 servidores corriendo el orquestador, ese setup sustituye ElastiCache Multi-AZ entero a coste marginal cero (los servidores ya están allí). La diferencia mensual real es el salario-equivalente de una persona, dependiendo del tamaño de la operación.

Preguntas que recibimos

¿Valkey es compatible con client libraries Redis? Sí, en 100% de los casos prácticos. El protocolo es idéntico — redis-cli, node-redis, ioredis, redis-rb, redis-py, go-redis, todos funcionan sin cambiar una línea. Lo que se cambia es solo el endpoint. En 2026, varias bibliotecas ya anuncian soporte explícito a Valkey en el README, pero eso es cosmético — el protocolo es el mismo.

¿Puedo migrar de Redis Labs gestionado a Valkey self-hosted sin downtime? Sí, con replicación. Configuras Valkey como réplica del Redis Labs (REPLICAOF host port), esperas sincronizar (algunos minutos a horas dependiendo del dataset), promueves Valkey a master (REPLICAOF NO ONE), haces cutover de DNS interno, decomisionas Redis Labs después de período de observación. Ventana de error real es de segundos durante el swap.

¿Dragonfly vale el riesgo de BSL? Depende del horizonte de la empresa. BSL convierte a Apache 2.0 después de 4 años por el modelo estándar — entonces código de hoy será abierto hasta 2030. El riesgo es que la empresa detrás (DragonflyDB Inc) siga el camino de Redis Inc y haga la conversión menos amigable. Para workloads que exigen performance que Valkey no entrega (por encima de 500k ops/s sostenido), Dragonfly puede ser la elección correcta a pesar del riesgo. Para el resto, Valkey es más conservador.

¿Cuánto de RAM consume un Redis con 1 GB de datos útiles? Cuenta práctica: dataset de 1 GB ocupa entre 1,3 y 2 GB reales de RAM (overhead de estructura, fragmentación, buffers de cliente, replication backlog). Configurar maxmemory en 60% de la RAM disponible es regla segura — instancia de 4 GB cabe ~2,5 GB de datos útiles con holgura.

¿Sidekiq necesita AOF de verdad? Los docs de Sidekiq dicen que se puede correr sin. Los docs dicen que técnicamente corre. En producción, sin AOF, cualquier restart inesperado pierde jobs enfilados que estaban en el buffer. Para cola de "envío de e-mail bienvenida", lo descubres cuando el cliente reclama. Para cola de "cobro recurrente", lo descubres cuando contable reclama. AOF es barato (incremento de 5-10% de I/O), el coste de no tenerlo es grande.

¿Cluster vs Sentinel para app procesando 50k jobs/día? Sentinel. 50k jobs/día son 0,6 ops/s media — caben en 100 MB de RAM Redis. Cluster es overkill por orden de magnitud. Sentinel resuelve failover automático con 1 master + 1 réplica + 3 sentinels (3 procesos sentinel en VPSs separados, pueden cohabitar con otras cosas).

¿ElastiCache São Paulo tiene latencia buena para app corriendo en São Paulo? Sí, 1-3ms p99 dentro de la misma AZ. El problema no es latencia — es coste y lock-in. Latencia solo se vuelve tema si la app está en otro proveedor (Hetzner FSN, DigitalOcean NYC) intentando hablar con ElastiCache São Paulo — ahí sube a 130-200ms y el argumento desaparece.

¿Cómo hacer backup de Valkey self-hosted que sobreviva a desastre? Tres capas. Primera: AOF persistente en disco local (sobrevive a restart). Segunda: snapshot RDB diario copiado para storage S3-compatible (Wasabi, Backblaze B2, Cloudflare R2 — todos más baratos que S3 de AWS para ese caso). Tercera: snapshot semanal copiado para otro proveedor de storage (segunda región, segundo proveedor). Restic o rclone hacen el trabajo. Coste total de almacenamiento para backup de Valkey de 4 GB: cerca de US$1/mes.

Cierre

En 2026, "Redis en producción" se volvió pregunta con más matiz de lo que tenía en 2023. La licencia del producto original cambió, el fork Linux Foundation maduró, alternativas multi-thread están de pie, la oferta serverless tiene caso de uso real. Elegir entre las cuatro implementaciones y los tres caminos gestionados es ejercicio honesto — no hay respuesta única.

Nuestra recomendación default para startup en 2026: Valkey auto-hospedado en un cluster propio, modo Sentinel, AOF activado si hay queue, monitoring con Prometheus. Coste en el rango de R$80–R$230/mes, contra R$600–R$2.000/mes de las alternativas gestionadas equivalentes. Compatibilidad total con cualquier biblioteca Redis. Sin exposición a la licencia RSAL. Migración reversible si se vuelve un problema.

Para poner ese stack de pie:

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

Y leer en paralelo: Postgres en producción: gestionado vs auto-hospedado (mismo análisis para la base de datos) y Cuánto cuesta alojar un SaaS en 2026 (la cuenta consolidada de todo el stack).