Valkey 9.1 frente a Redis 8: cuánta memoria ahorra por clave, medido

Valkey 9.1.2 necesitó 62,9 bytes por clave con 5 millones de claves de valor corto, frente a 70,9 de Valkey 9.0.6 y 81,5 de Redis 8.10.2. Lo medí el 7 de octubre de 2026 en Docker, con los mismos datos en los tres servidores. El ahorro de la versión 9.1 existe, pero solo aparece con valores cortos, y migrar desde Redis 8 tiene una dificultad de formato de fichero. También tienes la versión en inglés.

Puntos clave

• El blog de Valkey afirma que la 9.1 recorta la sobrecarga por clave "hasta un 44 %" en cadenas, y que compara 9.1 solo con 9.0, nunca con Redis.
• Con 5 millones de claves y valores de 16 bytes, Valkey 9.1.2 usó 62,9 bytes por clave: un 11,3 % menos que Valkey 9.0.6 y un 22,7 % menos que Redis 8.10.2.
• Con valores de 100 y 200 bytes, Valkey 9.0 y 9.1 empataron, y Redis 8 quedó 3,4 bytes por clave por debajo de los dos.
• Los hashes no cambian: 302 bytes por hash de 10 campos en Valkey 9.0 y 9.1, y 303,7 en Redis 8.
• Valkey 9.1 no carga RDB de Redis 7.4 ni de Redis 8 (ni por fichero, ni por replicación, ni con MIGRATE). Los comandos del cliente se comportaron igual en los dos servidores.

Qué promete Valkey 9.1 y qué no compara

La promesa del equipo de Valkey es precisa y menos amplia de lo que sugieren los titulares. La entrada Reducing Memory Overhead in Valkey 9.1^[1], del 13 de agosto de 2026, dice: "With Valkey 9.1, per-key memory overhead is cut by up to 44% for strings and up to 8.5 bytes per sorted set member, without changing a single command or configuration."

El rango de 17 a 44 % (26 % de media) sale de comparar Valkey 9.0 con 9.1 con 5 millones de elementos por prueba y distintos tamaños de clave y valor.

Tres cambios lo explican. Las cadenas incrustadas (embstr) pierden un puntero de 8 bytes. El umbral de embstr sube de 64 a 128 bytes. Los miembros de los conjuntos ordenados pasan a los nodos de la lista de saltos. La entrada no compara con Redis y avisa de que el ahorro exacto depende de las clases de tamaño de jemalloc.

Esa última frase es la que decide si te sirve. Aquí mido tres cosas que la entrada no cubre: la diferencia con Redis 8, los hashes y qué pasa al migrar. Para la migración, el post sobre Valkey como sustituto de Redis con Valkey 8.1 cubre el cambio de servidor. El de Valkey, el fork abierto tras el cambio de licencia explica el origen.

Cómo medí la memoria en Docker

Arranqué tres contenedores en la misma máquina (arm64, Linux), sin persistencia y con jemalloc 5.3.0 en los tres: valkey/valkey:9.0 (9.0.6), valkey/valkey:9.1 (9.1.2) y redis:8 (8.10.2). El servidor de Redis 8 de la imagen oficial lleva módulos cargados, por eso parte de una memoria base más alta (1,45 MB frente a 0,98 MB). Resto esa base en todas las cifras por clave.

services:
  valkey91:
    image: valkey/valkey:9.1
    command: ["valkey-server", "--save", "", "--appendonly", "no"]
    ports: ["29001:6379"]
  redis8:
    image: redis:8
    command: ["redis-server", "--save", "", "--appendonly", "no"]
    ports: ["29002:6379"]

El fichero de Compose tenía también valkey/valkey:9.0, igual que valkey91. Para cada conjunto de datos recreé los contenedores, generé las órdenes SET con awk y las cargué con --pipe, que envía todo el protocolo de una vez:

awk -v n=5000000 'BEGIN{
  v=sprintf("%16s",""); gsub(/ /,"x",v)
  for(i=0;i<n;i++){
    k=sprintf("user:%09d",i)
    printf "*3\r\n$3\r\nSET\r\n$%d\r\n%s\r\n$16\r\n%s\r\n",
           length(k),k,v}}' |
  docker exec -i b8p10-valkey91 valkey-cli --pipe

Las claves miden 14 bytes (user:000000000) y el valor 16, 100 o 200 bytes según la prueba. Tras la carga ejecuté MEMORY PURGE y leí INFO memory: la cifra de cada fila es used_memory menos la memoria base, dividido entre las claves. La carga del equipo era alta (la media de carga superó 24 durante la sesión), así que no publico tiempos ni rendimiento: la memoria usada no depende de esa carga.

Resultados: bytes por clave con 1 y 5 millones de claves

Con valores cortos, Valkey 9.1 gana a las dos versiones anteriores, y la ventaja se esfuma con valores de 100 bytes. Este gráfico recoge los bytes por clave (o por hash) de cada servidor, tras restar la memoria base:

Con 1 millón de claves y valor de 16 bytes, la 9.1 ahorra 8 bytes por clave (un 10,9 %) frente a la 9.0 y un 6,6 % frente a Redis 8. Con 5 millones, la diferencia con Redis 8 sube al 22,7 %, porque Redis 8 pasó de 70,2 a 81,5 bytes por clave al crecer el conjunto.

No investigué la causa: repetí la carga de 5 millones dos veces más y obtuve 408,8 MB en cada una, así que el resultado es estable. La memoria residente del proceso (RSS) sigue el mismo orden con 5 millones de claves. Son 335,1 MB en Valkey 9.1, 374,7 MB en Valkey 9.0 y 434,1 MB en Redis 8.

Dónde empieza y dónde termina el ahorro

La entrada de Valkey sugiere comparar MEMORY USAGE en una clave representativa, y eso hice con valores de distinto tamaño y la clave de 14 bytes. MEMORY USAGE incluye la clave, el valor y la sobrecarga, y esta tabla da los bytes que informa cada servidor:

La 9.1 ahorra entre 8 y 24 bytes por clave mientras el valor cabe en embstr.

En mis pruebas lo hizo hasta 96 bytes de valor, y con 100 bytes pasó a raw y la ventaja desapareció. Descuenta de cada fila los 14 bytes de la clave y el valor. La sobrecarga baja de 26 a 18 bytes con valores de 8 y 16 bytes, y de 42 a 18 con 64 y 80. Por tanto, el porcentaje depende de tu tamaño de valor, tal y como avisa el blog.

Hay un dato más: a partir de 100 bytes, Redis 8 usa 7 bytes menos por clave que las dos versiones de Valkey. Un caché de sesiones o de contadores, con valores de decenas de bytes, es donde la 9.1 compensa. Un caché de fragmentos HTML o de JSON no ve ninguna mejora.

Qué pasa al migrar de Redis 8 a Valkey 9.1

La migración desde Redis 8 no funciona por los medios habituales: Valkey 9.1 no entiende el formato de fichero que escribe Redis desde la versión 7.4. La guía oficial de migración^[2] lo dice así: "RDB files produced by Redis CE 7.4 and later are not compatible." Lo probé con una instantánea de cada versión de Redis cargada en Valkey 9.1.2:

El fallo no depende de cómo llegue el fichero. Con REPLICAOF b8p10-redis8 6379 en Valkey 9.1, el enlace con el primario se quedó en down y el registro repitió el mismo error al cargar la sincronización. Con MIGRATE (que usa DUMP y RESTORE) respondió "DUMP payload version or checksum are wrong". El sentido contrario tampoco sirve: Valkey 9.1 escribe VALKEY080 en la cabecera y Redis 8.10.2 se detuvo con "Wrong signature trying to load DB from file".

Lo que sí funciona es copiar por comandos. Ejecuté la misma lista de 25 órdenes en Valkey 9.1.2 y en Redis 8.10.2, con cadenas, hashes, listas, conjuntos, conjuntos ordenados, streams, HyperLogLog, geoespacial y scripts Lua. Las salidas fueron idénticas salvo MEMORY USAGE de una cadena de 112 bytes: 160 contra 153. Para mover datos entre las dos familias sirven las herramientas que leen y escriben por comandos, como RedisShake^[3] o RIOT, que no probé aquí.

Si tu origen es Redis 7.2 o anterior, el fichero RDB y la replicación sí valen, tal como confirma la guía.

Cuándo compensa pasar a Valkey 9.1

Pasa a Valkey 9.1 si tu memoria la dominan millones de claves con valores de menos de 96 bytes y puedes recargar los datos desde la fuente. Mide antes con tus claves reales: MEMORY USAGE y OBJECT ENCODING sobre diez claves representativas en un Valkey 9.0 y un 9.1 te dan la respuesta en cinco minutos. Si tu caché guarda valores grandes o hashes, el ahorro es 0, y migrar solo aporta licencia y gobernanza, no memoria.

Si ya tienes Redis 8 y lo usas con búsqueda vectorial o módulos, Valkey no es un sustituto directo: la imagen de Redis 8 trae módulos que Valkey no incluye de serie. Para probar cualquiera de los dos en un servidor propio, la guía de Redis con Docker arranca en dos minutos el lado de Redis, y la imagen valkey/valkey se levanta igual.

Preguntas frecuentes

¿Cuánta memoria ahorra Valkey 9.1 respecto a Redis 8?

Depende del tamaño del valor. Con valores de 16 bytes y 5 millones de claves, un 22,7 % (62,9 contra 81,5 bytes por clave). Con valores de 100 bytes o más, Redis 8 usó unos 3,4 bytes menos por clave, y con hashes la diferencia fue del 0,6 %.

¿Puedo cargar un RDB de Redis 8 en Valkey 9.1?

No. Valkey 9.1.2 rechazó los ficheros de Redis 7.4.9, 8.6.3 y 8.10.2 (versiones 12, 13 y 15). Solo cargó el de Redis 6.2.24 (versión 9). La replicación y MIGRATE fallaron con el mismo motivo, así que hay que copiar por comandos.

¿Tengo que cambiar mi aplicación para usar Valkey 9.1?

No. Mis 25 órdenes de prueba dieron el mismo resultado que en Redis 8.10.2 con el mismo cliente. La entrada de Valkey dice lo mismo: el ahorro llega "without changing a single command or configuration".

Conclusión

Valkey 9.1 cumple lo que promete para cadenas cortas: 8 a 24 bytes menos por clave que Valkey 9.0. Con 5 millones de claves usa 62,9 bytes por clave, frente a 81,5 de Redis 8.10.2. Fuera de ese rango (valores de 100 bytes o más, hashes) el ahorro es 0, y el obstáculo real de migrar desde Redis 7.4 o posterior es el formato RDB.

Antes de decidir, mide tus propias claves y comprueba qué versión de Redis tienes. Si es 7.4 o superior, planifica una copia por comandos en lugar de un fichero.

Fuentes: [1] Reducing Memory Overhead in Valkey 9.1^[1], [2] Valkey 9.1 delivers improvements in security, performance, and more^[4], [3] Migrating from Redis to Valkey^[2], [4] Comando MEMORY USAGE en la documentación de Redis^[5], [5] Imagen oficial valkey/valkey en Docker Hub^[6], [6] Imagen oficial redis en Docker Hub^[7].

Fuentes

1. Reducing Memory Overhead in Valkey 9.1
2. guía oficial de migración
3. RedisShake
4. Valkey 9.1 delivers improvements in security, performance, and more
5. Comando MEMORY USAGE en la documentación de Redis
6. Imagen oficial valkey/valkey en Docker Hub
7. Imagen oficial redis en Docker Hub