📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Tengo una manía con los respaldos: primero medir cuánto pesa el original, después cuánto pesa el respaldo. La semana pasada recaí en un cambio que suena menor pero que a ti, si administras un VPS con Redis o Valkey, te debería interesar: Valkey 9.2 incorpora compresión de stream completo para los archivos RDB con LZ4, y la diferencia respecto del compresor de siempre es de otro planeta. La medición completa la publicó Alex Georgiev, y los números son verificables.
El default de casi veinte años casi no comprime
Contexto rápido por si llegaste tarde: cuando Redis cerró su licencia en 2024, la comunidad lo forkeó y nació Valkey, hoy mantenido por la Linux Foundation. Mismo protocolo, mismo cliente, y una trayectoria propia. La 9.2 salió como release candidate en septiembre, va a GA en noviembre, y una de sus novedades es rdbcompression con LZ4: en vez de comprimir cada valor por separado con LZF, comprime el archivo serializado completo como un solo stream.
Por qué importa: LZF solo busca repetición dentro de cada valor. Un registro JSON de 150-200 bytes no tiene casi nada que apurar por dentro, así que LZF corre, cobra su CPU, y devuelve nada. La prueba con un millón de claves tipo perfil de usuario: sin compresión, 180,3 MB. Con el default LZF: 177,6 MB, un ahorro del 1,5% por pagar compresión todo el tiempo. Con LZ4 de stream completo: 35,4 MB, un 80% menos, con apenas un 6% más de CPU que el LZF que ya estabas gastando. La razón es simple: los nombres de campos y los valores repetidos cruzando el millón de registros —"active":true, roles iguales, la misma estructura— son redundancia que LZF estructuralmente no puede ver y LZ4 sí.
La trampa: son dos parámetros, no uno
Acá está lo más valioso de todo el experimento. El autor activó la compresión y midió un full sync hacia una réplica: los bytes transmitidos fueron idénticos, sin ningún warning. ¿La explicación? rdbcompression solo cambia el archivo en disco. El stream que el primario manda a la réplica en una sincronización completa se controla con otro parámetro aparte, repl-compression, que viene apagado por defecto. Cuando lo activó, el mismo sync bajó de 17,6 MB a 3,4 MB. Si tú solo pones el primero en un primario con réplicas, crees que configuraste la función y en realidad configuraste la mitad. Ese tipo de silencio es el que después te llena el disco sin que sepas por qué.
Segunda trampa: flota mixta. Una réplica vieja (8.1) y una 9.2 contra el mismo primario sincronizan bien —la antigua cae a texto plano sin error—, pero el primario hace dos pases de BGSAVE separados. En una máquina chica, ese fork doble en la misma ventana es justo lo que no necesitas.
Cuándo esto no sirve para nada
Con 200.000 claves de tokens hex aleatorios de 32 bytes —sesiones, API keys, counters— LZ4 ahorró un 4,7% y costó un 35% más de tiempo que LZF. Si tu base está llena de datos que ya parecen ruido, la compresión nueva es pura sobrecarga. La ganancia es de los datos, no del algoritmo: mientras más estructura repetida cruzando registros, más rinde.
Mi lectura de sysadmin: este es el tipo de cambio que más me gusta en software de infra. Aburrido, medible, gratis, sin migración. Y la lección no es LZ4: es que los defaults pesan más que los features. LZF llevaba años cobrando CPU por un 1,5%. Cuando revises tus servidores, mira los defaults con la misma lupa que las opciones nuevas —en mi pega hay varios parámetros que heredé configurados por inercia y que nunca los había escuchado. La 9.2 todavía es RC: no corre a actualizar producción hoy, pero si respaldas RDB nocturnos y tienes réplicas, márquela en la lista para el GA de noviembre.
Fuente de inspiración: Valkey 9.2’s new rdbcompression lz4 setting cuts a 1M-row RDB from 178MB to 35MB
