Redis y el costo de la ambición
(charlesleifer.com)- Redis llegó al punto de revisar un gran PR para agregar el array type en 2026, mostrando cómo pasó de ser un simple servidor de estructuras de datos a un producto que intenta abarcar múltiples áreas
- El Redis inicial, fiel a Remote Dictionary Server, se posicionó rápido en el stack web gracias a su diccionario en memoria veloz, comandos acotados y protocolo simple
- En la última década, Redis se expandió con Streams, JSON, search, graph, time-series, Redis-Raft, vector sets y más, reforzando su orientación hacia una database
- La expansión de funciones debilitó la simplicidad y consistencia que eran fortalezas de Redis, y aumentó las integraciones a medio cocer en áreas donde se necesitan herramientas especializadas
- Valkey, en lugar de perseguir funciones vistosas, se enfoca en rendimiento multihilo, eficiencia de memoria y confiabilidad del clúster, apuntando a la base de usuarios del Redis estilo 2011
La identidad que Redis perdió
- Redis llegó al punto de evaluar un gran PR para agregar un array type en 2026, y eso simboliza su transformación de un simple servidor de estructuras de datos en un producto que busca cubrir múltiples dominios
- El array type PR de antirez parte del problema de que Hash, List y Stream tienen fortalezas respectivas en acceso aleatorio, append/trim y eventos append-only, pero no ofrecen al mismo tiempo acceso intermedio y visibilidad por rangos como un arreglo
- Redis ya tiene funciones que pueden usarse como arreglos, como los arreglos JSON, time-series y sorted-set, pero el hecho mismo de querer agregar otro tipo nuevo deja en claro la naturaleza de esta expansión funcional
- El problema central es que se está debilitando aquello que explicó el éxito inicial de Redis: la simplicidad, un protocolo claro, comandos acotados y ortogonales, y consistencia conceptual
Los cambios de la última década
-
La licencia y la dirección de la empresa
- Redis Inc abandonó la licencia BSD en 2024, y luego retrocedió a un esquema de triple licencia que incluye AGPLv3 como única opción OSI
- Gracias a AGPLv3, Redis Inc puede decir que es open source, pero es una licencia de naturaleza muy distinta a BSD
- La empresa respaldada por VC detrás de Redis originalmente era Garantia Data, un servicio de hosting cloud de NoSQL; luego se movió al hosting de Redis, cambió su nombre a uno de la familia Redis y sumó a antirez para ganar legitimidad
- El proceso por el que años después recibió la marca registrada sentó la base para el posterior cambio de licencia, y los textos y comentarios de aquella época hoy se ven envejecidos de una forma predecible
-
Expansión funcional y posicionamiento del producto
- Redis empezó con un pequeño conjunto de tipos de datos útiles, pero con el tiempo incorporó estructuras de datos exóticas, sistemas stateful complejos como Streams, e incluso módulos con un carácter semiprivativo según la versión
- En 2026, el posicionamiento de la landing page de Redis pasó a ser “The Real-Time Context Engine for AI Apps”
- En la landing page aparecen juntos los botones “Try Redis for Free” y “Get a Demo”, como puede verse también en esta captura
-
La orientación hacia una base de datos web scale
- Funciones como Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex® y Redis-on-Flash® muestran que Redis ha venido apuntando a ser una “base de datos web scale”
-
Cambios de protocolo y caché del lado del cliente
- RESP3 rompe en varios puntos el supuesto básico del modelo request/response de RESP2, y se lo evalúa como algo cercano al patrón de fracaso del segundo sistema que describía Brooks
- Redis se usó ampliamente como caché desde el principio, pero ahora llegó al punto de necesitar un protocolo nuevo para soportar caché del lado del cliente
Por qué el Redis inicial encajó tan bien
-
El contexto de la época
- Alrededor de 2011, entre desarrolladores web pegaban fuerte corrientes como NoSQL, “web scale”, Bigtable, Dynamo, Ruby on Rails, REST y JSON
- Redis encajó muy bien en ese clima y se convirtió casi de la noche a la mañana en una herramienta presente en muchísimos stacks
- A fines de 2011, la presentación de Redis se describía a sí misma como advanced key-value store y data structure server, y no usaba la palabra “database”
-
Un diccionario remoto mejor que Memcached
- memcached era infraestructura esencial que corría silenciosamente en muchos servidores web, y además de caché se usaba seguido para locks, contadores y rate limiting temporales
- En ese momento, Redis era percibido como algo cercano a “memcached but way better”, y su propio nombre, Remote Dictionary Server, reforzaba esa idea de diccionario rápido en memoria
- Redis ofrecía no solo blobs de bytes, sino también estructuras bien elegidas como linked-list, hash-table, set y sorted-set, lo que amplió mucho sus usos prácticos y temporales
-
Un protocolo simple pero suficientemente expresivo
- El wire protocol de Redis era lo bastante simple como para entenderlo e implementarlo en una hora, pero también lo bastante potente como para expresar varios tipos de datos
- Las bibliotecas cliente eran simples y limpias de implementar, y el protocolo en sí se sentía natural
- El tutorial write your own Redis para construir un servidor Redis simple y su protocolo sigue siendo un artículo popular escrito hace unos 10 años
-
Un solo hilo, basado en eventos y en memoria
- El diseño de single-thread de Redis garantizaba la atomicidad de todas las operaciones, reduciendo mucho la complejidad y facilitando el razonamiento
- Para que un solo hilo funcionara, el servidor debía implementarse con non-blocking I/O, y las operaciones de datos también debían ser muy rápidas
- Esa combinación hacía posible un key/value store veloz capaz de atender a muchos clientes con un solo hilo
-
Estructuras de datos adecuadas para aplicaciones web
- Los strings con expiración servían para caché, las listas para colas y los hashes para datos estructurados
- También era fácil construir con los tipos integrados cosas como locks, contadores, rate limiting, liveness, monitoreo y leaderboards
La ambición de convertirse en database
- La adopción de Redis creció rápido y tuvo un enorme éxito, pero en algún punto la ambición del proyecto cambió hacia convertirse en una database
- Algunas funciones sí fueron realmente útiles; por ejemplo,
BZPOPMIN, agregado en Redis 5.0, permitió hacer blocking pop sobre sorted-set usados como priority queue y aumentó su utilidad práctica - En cambio, funciones como ACL se sentían poco propias de Redis, y en general se hizo evidente el deseo de convertir a Redis en todo para todos
- Las adiciones funcionales de Redis también reflejan ese impulso por seguir la “última moda” de la que los desarrolladores hablaron en Hacker News durante la última década
- Como MongoDB almacena JSON, Redis también tenía que convertirse en una document database
- Como ElasticSearch ofrece full-text search, Redis también tenía que volverse un search engine
- Cuando las graph database ganaron atención, Redis también quiso ser una graph database, pero eso luego terminó en RedisGraph EOL
- Cuando Kafka ganó atención, Redis también quiso ser una event streaming platform
- Cuando ZooKeeper y las bases de datos con consistencia fuerte se volvieron importantes, apareció Redis-Raft, y el análisis de Jepsen de Aphyr es considerado lectura casi obligatoria
- Cuando InfluxDB ganó atención, Redis también quiso convertirse en una time series database
- Y para no quedarse atrás en la ola de AI, también hicieron falta funciones relacionadas como vector sets
El costo de expandir funciones
- El primer problema es que Redis termina debilitando por sí mismo los factores que lo volvieron una herramienta esencial en el stack de todos
- Redis era simple, sus comandos eran ortogonales y acotados, su protocolo era limpio y era una herramienta conceptualmente coherente
- El segundo problema es que quien de verdad quiere integrar full-text search, procesamiento de event streams, key/value con consistencia fuerte, time-series y almacenamiento vectorial no busca módulos a medio cocer heredando las limitaciones de Redis, sino herramientas especializadas
- La alta disponibilidad de Redis es compleja, la persistencia tiene trade-offs sutiles, y la carga del protocolo junto con la fragmentación de clientes también son obstáculos reales
- La postura es que Redis no es una herramienta para reemplazar a Postgres, y que sistemas como ElasticSearch y RabbitMQ deben seguir siendo pilares propios
- El análisis de Aphyr sobre una implementación temprana de Redis-Raft dice haber encontrado 21 problemas
- largos periodos de indisponibilidad en clústeres sanos
- 8 crashes
- 3 stale reads
- 1 aborted read
- 5 bugs que llevaban a pérdida de updates ya committeados
- 1 loop infinito
- 2 problemas que podían enviar respuestas lógicamente corruptas al cliente
- la primera versión probada,
1b3fbf6, fue evaluada como algo prácticamente inutilizable
- Redis como caché y servidor de estructuras de datos y un “Redis the etcd” o un Redis orientado a otras bases de datos especializadas son propuestas fundamentalmente distintas, y esa brecha es el problema central
Disque reveló el mismo patrón
- En 2015, antirez presentó Disque y explicó que no partió de casos de uso reales, sino que lo diseñó en “astronaut mode” viendo a gente usar Redis como message queue y observando otros message queues
- Un proyecto hecho como reto personal o aprendizaje, sin casos de uso reales de partida, puede ser excelente, pero otra cuestión es si puede seguir resolviendo la larga cola de problemas difíciles que aparecen cuando crece la base de usuarios
- La entrega de mensajes con alta disponibilidad es un problema genuinamente difícil, y no importa qué lado del teorema CAP se optimice: no se pueden evitar los trade-offs ni los problemas duros
- En 2015 ya había muchos message brokers maduros, y la razón por la que la gente usaba Redis como message broker era que ya usaban Redis y que era suficientemente simple
- Lo que se necesitaba no era un nuevo message broker, ni que Redis se convirtiera en un message broker más complejo
- Disque se volvió prácticamente abandonware poco después de su anuncio, y aunque obtuvo 8K stars en GitHub, quedó abandonado
- Más tarde fue reescrito como módulo de Redis, pero ese proyecto también lleva 7 u 8 años abandonado
Valkey muestra otra dirección
- Las fuerzas que movieron la trayectoria de Redis se presentan como una mezcla de la ambición de los desarrolladores por resolver problemas complejos, la ambición de ser todo para todos y la ambición del propietario de Redis por extraer el máximo ingreso posible antes de ceder terreno frente a AWS y GCP
- La ambición en sí no es el problema, pero sí lo es cuando hace que se pierdan las razones del éxito original
- La existencia y adopción de Valkey se presentan como el juicio final de un mercado más amplio sobre esa dinámica
- En lugar de perseguir funciones llamativas o bullet points en tablas comparativas, Valkey invierte en trabajo menos vistoso: rendimiento multihilo, eficiencia de memoria, confiabilidad del clúster y mejoras de throughput
- Los benchmarks de rendimiento de Valkey son impresionantes, y apuntan directamente al 80% de usuarios de Redis para quienes las capacidades del Redis de 2011 siguen siendo suficientes
- En el mundo de Valkey, la conclusión es que no hace falta un nuevo array type
1 comentarios
Opiniones de Lobste.rs
Habiendo visto cómo se hace crecer un proyecto open source a una escala bastante grande, fundado una empresa, pasado por cientos de millones de dólares en ingresos, una IPO y hasta una venta por miles de millones, y habiendo incluso hecho un cambio de licencia para salir del OSS, la posición de Redis como “motor de contexto en tiempo real para apps de IA” parece correcta en términos de dirección.
En la compra de software existen los usuarios reales y los responsables de decisión técnica (TDM), y la landing page de Redis parece un sitio dirigido a TDM con presupuesto más que a desarrolladores usuarios finales. Muchos TDM prefieren decisiones por las que no los vayan a despedir, en el estilo de “nadie fue despedido por elegir IBM”, y si Gartner o McKinsey enfatizan la estrategia de IA y la gestión de contexto, entonces “Context Engine para apps de IA” se vuelve una razón de compra defendible.
En HashiCorp también intentaron separar terraform.io para practicantes y hashicorp.com para TDM, y hasta cierto punto funcionó, aunque también tuvo límites. Es un problema difícil para empresas de OSS impulsadas por desarrolladores.
Los botones de “usar Redis gratis” y “solicitar demo” tampoco son extraños desde la perspectiva de un TDM. Los TDM no quieren cargar con la responsabilidad de una decisión técnica y más bien prefieren pagar y comprar software, así que lo gratuito se rebaja a algo tipo prueba, y se pone al frente un llamado a la acción que conecte con una persona.
Parece que la dirección de Redis Inc. concluyó que era más importante apelar a los TDM que a desarrolladores/operadores. Sin datos internos es difícil decir si está bien o mal, pero no parece una estrategia hecha sin intención.
El hecho de seguir agregando funcionalidades también se debe a que el costo de expandir una herramienta existente es mucho menor que el de adoptar una nueva. Incluso sin motivación comercial, a muchos lenguajes de programación les pasa que, en vez de preservar su identidad central, terminan convirtiéndose en el mínimo común denominador de todas las funciones; en empresas comerciales, además, opera con fuerza la lógica de “land and expand”. Primero cierran el contrato con una función principal y luego, aunque vendan funciones adicionales de nivel promedio, para compras es mucho más fácil ampliar un contrato existente que tramitar uno nuevo.
También es muy discutible la idea de que “los clientes serios van a querer productos realmente especializados para búsqueda especializada/event streams/KV de consistencia fuerte/series de tiempo/vector stores”. Incluso viendo solo datos de empresas de software público, los clientes a menudo eligen opciones peores por razones no técnicas.
También es difícil afirmar tajantemente que Valkey sea el veredicto final del mercado. A Valkey le está yendo muchísimo mejor que al fork promedio (https://redmonk.com/sogrady/2026/04/06/valkey-at-two/), pero la empresa Redis también parece estar aguantando bien desde afuera. Si miras compañías como ElasticSearch o MongoDB, que cambiaron la licencia y aun así tuvieron forks sin que eso golpeara demasiado su valoración en el mercado público, también se puede llegar a otra conclusión. En la burbuja de desarrolladores puede verse distinto, pero si los ingresos son el indicador final y rezagado, también se podría preguntar: “¿de verdad importó tanto?”.
No intento defender los intereses comerciales, solo compartir la perspectiva desde ese lado. Es parecido a cómo, frente al mismo producto agrícola, quien hace las compras y quien cultiva tienen preguntas y objetivos completamente distintos.
Aun así, esta lógica da la sensación de asumir que el objetivo de todos es el dinero. La ambición de ganar muchísimo dinero con Redis es solo un tipo particular de ambición, y por la actitud que mostró antirez en el texto, no se lee como alguien a quien le importara tanto el dinero.
Como contraejemplo está SQLite. No habla de cientos de millones en ingresos ni de ventas por miles de millones, sino que se concentra silenciosamente en ofrecer algo bien definido. SQLite no perdió la razón por la que se convirtió en la base de datos embebida más popular, y del lado de las bases de datos grandes, Postgres pasa por algo parecido. En este mundo también se pueden sacar tantos contraejemplos como en el mundo del dinero y los intereses comerciales.
En el caso de Redis, parece que “ya usamos AWS/GCP, así que usemos algo parecido a Redis de ellos” es un resultado natural de la expansión horizontal. Una ruta todavía más tipo IBM es elegir un proveedor cloud y usar su Redis; hoy en día eso termina siendo Valkey.
Que la gente elija opciones peores no es materia de debate sino un hecho, y que Redis se haya expandido en ese modo es justamente un ejemplo de la ambición y deriva que quería enfatizar.
Antes
redis.comera el sitio para TDM yredis.ioera para desarrolladores, pero después de que Redis Labs se quedara con redis.io, que estaba en manos de antirez, lo arruinaron hasta el punto de que incluso encontrar el enlace de descarga se volvió difícil, y ahora ambas URLs te mandan a sitios para TDM. Incluso ahora sigue siendo difícil encontrar fácilmente el enlace de descarga de Redis; dan ganas de decirle a la gente que lo busque por su cuenta.El problema central es que Redis Labs siempre contrató liderazgo de marketing pésimo. Llegaban CMO y VP, quemaban toda la buena voluntad posible en poco tiempo y seis meses después se iban hacia “su próxima aventura”. Cuando vieron que el tráfico de redis.io era mucho mayor que el de redis.com, da la impresión de que destruyeron redis.io con la esperanza de que la gente que no encontraba el enlace de descarga hiciera clic en “try free”; un ejemplo típico de esa obsesión cortoplacista por los clics.
Vender funciones adicionales también ayuda a diferenciarse frente a la competencia en la lista de checkboxes. Eso aplica especialmente cuando es difícil competir por precio: AWS podía empaquetar fuertes descuentos cloud con ElastiCache, y el peor competidor de todos era Redis open source, que era gratis.
Valkey tiene muchísimo más dinero detrás que un fork típico. Por ejemplo, el exresponsable de relaciones con desarrolladores de Redis Labs ahora está en AWS trabajando en Valkey.
Aun así, da pena la idea de que Valkey solo hace “trabajo poco glamoroso”. Redis ya era multihilo desde hace mucho tiempo; el plano de control sigue siendo de un solo hilo, pero el I/O es multihilo, así que el trabajo de Valkey no es tan novedoso como cree quien escribió eso.
Valkey es abiertamente una operación para que empresas cloud como AWS puedan seguir vendiendo Redis sin pagarle dinero a nadie. Cualquier otra narrativa es solo una herramienta de marketing para convencer de que les dejen seguir haciendo lo que quieren hacer, y si concluyen que romper la compatibilidad con Redis les conviene comercialmente, lo harán. Ya apostaría moderadamente a que algo de eso pudo haber pasado en ambos lados, aunque no lo he seguido lo suficiente.
Si quieres un fork de Redis de verdad, enfocado en hacer el trabajo poco glamoroso mientras mantiene la simplicidad, ahí está redict.
Aun así, creo que el tiempo de Redis se está acabando. En el extraño panorama comercial actual, cada fork cojea por algún lado. Incluso redict, que quizá sea el más virtuoso, no parece tener un interés real por empujar Redis hacia adelante del mismo modo en que antirez impulsaba el proyecto original como un dictador benevolente. No quiero decir que sea malo que el software quede “terminado”, pero sí creo que Redis todavía tiene territorios geniales por explorar, y dudo que los forks comerciales vayan a crear ese tipo de ecosistema. Claro, también podría estar subestimando el valor de Arrays y de las aplicaciones relacionadas con IA, así que intento mantenerme abierto.
Viéndolo en retrospectiva, es sorprendente lo mal que Redis Labs arruinó todo esto, y por suerte ya pasó suficiente tiempo como para que me enoje menos.
En el trabajo estamos armando un sistema de cola de tareas más justo con scripts en Lua, y Redis se siente muy raro. Mi modelo mental siempre fue “un simple almacén clave-valor”, pero termino aprendiendo todo tipo de funciones, como ejecutar scripts en Lua dentro de un bloqueo global.
Pero la documentación está montada en un sitio web brillante y no te lo deja claro. Incluso los valores de configuración se explican solo dentro de ejemplos de configuración.
Sé que Redis funciona bien y todo el mundo lo dice, pero la experiencia de ir aprendiendo sus funciones es bastante incómoda. Se siente como si alguien hubiera hecho un programa realmente bueno y luego se hubiera olvidado de la excelente documentación que normalmente acompaña a un buen programa.
Es una queja rara. Redis parece funcionar extremadamente bien, y me gustan documentos como los de Postgres, que explican “todo”.
Muchos proyectos open source también saben muy bien que su documentación es débil, así que en este experimento no parece que la única variable sean los jefes de pelo en punta.
La documentación de redict también se ve buena: https://redict.io/docs/scripting/