Categoría: Bases de datos
Valkey gestionado: la alternativa abierta a Redis, en vuestra cuenta
El almacén en memoria compatible con Redis que mantiene la Linux Foundation con licencia BSD, instalado o migrado en vuestra cuenta, con la compatibilidad revisada antes de cambiar nada.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Open source, BSD 3-Clause
En resumen
Valkey es un almacén de clave y valor en memoria, de código abierto con licencia BSD, que nació en 2024 como bifurcación de Redis bajo la Linux Foundation. Habla el mismo protocolo, así que la mayoría de aplicaciones funcionan sin cambios. Lo instalamos en vuestra cuenta o migramos vuestro Redis actual, revisamos clientes y módulos, configuramos réplicas y copias y lo mantenemos actualizado.
¿Qué nos encargamos de mantener?
Valkey se opera igual que Redis: persistencia, réplicas, memoria y copias. Eso lo contamos con detalle en Redis y Valkey gestionados. Esta página trata de lo que cambia cuando elegís Valkey o migráis a él:
Inventario
Versión de origen, comandos, scripts Lua, módulos y clientes que tocan vuestro Redis actual.
Compatibilidad
Pruebas de la aplicación contra Valkey en un entorno aparte, con los mismos datos.
Migración
Réplica en vivo, copia RDB o llenado natural de la caché, según el caso.
Réplicas
Sentinel o modo clúster, igual que en Redis, con la conmutación probada.
Métricas
Exportador de Prometheus compatible y alertas de memoria, réplica y expulsiones.
Versiones
Seguimiento de las versiones de Valkey, que ya añaden funciones propias.
¿Cómo migramos de Redis a Valkey?
El método depende sobre todo de la versión de Redis de la que partís y de si los datos se pueden perder:
| Situación | Cómo lo hacemos | Corte |
|---|---|---|
| Caché que se puede reconstruir | Apuntamos la aplicación a Valkey y dejamos que se llene | Ninguno, solo más carga en la base de datos un rato |
| Redis 7.2 o anterior, con sesiones o colas | Valkey como réplica del Redis actual y conmutación controlada | Segundos, al cambiar la conexión |
| Redis 7.4 u 8 | Copia de claves en vivo con una herramienta de migración y comprobación de recuentos | Corto, en una ventana pactada |
| Servicio gestionado del proveedor | Cambio de motor desde el propio servicio cuando lo permite | Según el proveedor; lo ensayamos antes en una copia |
Antes de producción, la aplicación pasa sus pruebas contra Valkey con una copia de los datos. Y dejamos preparado el camino de vuelta: el Redis antiguo sigue disponible hasta que todo funciona.
¿Qué problemas encontramos en una migración?
- Comandos nuevos de Redis que la aplicación empezó a usar tras la bifurcación y que Valkey no tiene o implementa distinto.
- Módulos de Redis Stack de los que nadie se acordaba, como búsqueda o JSON.
- Copias que no cargan: un archivo de persistencia de Redis reciente que Valkey no reconoce.
- Clientes muy antiguos que comprueban el nombre del servidor o la versión y se confunden.
- Monitorización atada a Redis: paneles y alertas que dependen de campos concretos de INFO.
- Sin vuelta atrás: el Redis original apagado antes de comprobar que todo funciona.
¿Por qué existe Valkey?
Hasta la versión 7.2, Redis tenía licencia BSD. En 2024 su empresa la cambió por una licencia doble, RSALv2 y SSPLv1, que no son de código abierto según la OSI. Pocos días después, antiguos mantenedores y varias empresas crearon Valkey a partir de Redis 7.2.4 bajo la Linux Foundation, con la licencia BSD de siempre. Más tarde, Redis 8 añadió la AGPLv3 como opción de licencia abierta. Desde la bifurcación, los dos proyectos avanzan por separado y cada uno añade funciones propias, así que la compatibilidad total es la de la versión de partida.
¿Para quién tiene sentido?
- Una empresa cuya política exige licencias abiertas aprobadas por la OSI y permisivas para todo lo que corre en producción.
- Un equipo en AWS, Google Cloud, DigitalOcean u OVHcloud cuyo servicio de caché gestionado ya ofrece Valkey como opción principal.
- Quien parte de cero con caché, colas o sesiones y no depende de módulos propios de Redis.
Si vuestra aplicación usa funciones o módulos propios de Redis 8, seguir en Redis es una decisión razonable y la gestionamos igual. Las métricas acaban en la monitorización con Grafana y Prometheus.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores cloud con Valkey y Sentinel en tres máquinas y red privada, con copias RDB a Object Storage de Hetzner. | Sin caché gestionada: réplica, conmutación y copias las montamos nosotros. |
| AWS | ElastiCache para Valkey, o EC2 con Valkey y Sentinel si necesitáis algo que el servicio no permite. | El paso de ElastiCache para Redis OSS a Valkey se hace desde el propio servicio; lo planificamos y revisamos la versión de los clientes. |
| Google Cloud | Memorystore for Valkey, con modo clúster si los datos no caben en un nodo. | |
| DigitalOcean | Managed Caching for Valkey, o Droplets con Valkey y Sentinel. | |
| OVH | Valkey gestionado de OVHcloud Public Cloud, o instancias con Valkey montado por nosotros. | |
| Servidor propio | Valkey en vuestros servidores o máquinas virtuales, con Sentinel en tres máquinas y copias a un almacenamiento S3 externo. |
Qué incluye
- Valkey en vuestra cuenta cloud o en vuestros servidores, o el servicio gestionado para Valkey de vuestro proveedor si encaja mejor.
- Inventario previo de lo que usa vuestro Redis: versión, comandos, módulos, scripts Lua y bibliotecas cliente.
- Migración desde Redis con réplica en vivo o a partir de una copia, según la versión de origen.
- Pruebas de la aplicación contra Valkey en un entorno aparte antes de cambiar producción.
- Réplicas con Sentinel o modo clúster, persistencia elegida según el uso y maxmemory ajustado.
- Usuarios con ACL por aplicación, TLS y acceso solo desde la red privada.
- Métricas en Prometheus y alertas de memoria, expulsiones, conexiones y réplica retrasada.
- Copias RDB fuera del servidor, restauración probada y actualizaciones réplica a réplica.
Preguntas frecuentes
¿Tenemos que cambiar el código de nuestra aplicación para pasar a Valkey?
Normalmente no. Valkey usa el mismo protocolo y los mismos comandos que Redis 7.2, así que las bibliotecas cliente habituales conectan sin cambios. Lo que revisamos es si usáis comandos o estructuras añadidos en versiones de Redis posteriores a la bifurcación, o módulos que no existen en Valkey.
¿Podemos migrar desde Redis 7.4 u 8?
Sí, pero con más cuidado. Esas versiones evolucionaron por su cuenta y cambiaron el formato de los archivos de persistencia, así que restaurar su copia en Valkey no siempre funciona. En ese caso copiamos las claves en vivo con una herramienta de migración o dejamos que la caché se llene sola, y comprobamos antes qué comandos nuevos usa la aplicación.
¿Valkey tiene los módulos de Redis, como búsqueda o JSON?
Valkey tiene sus propios módulos, mantenidos por el proyecto, para algunas de esas funciones, pero no son los mismos que Redis Stack ni tienen siempre la misma interfaz. Si dependéis de un módulo concreto, lo probamos antes de proponeros el cambio; a veces lo sensato es quedarse en Redis.
¿Por qué los proveedores cloud están pasando a Valkey?
Porque Valkey mantiene la licencia BSD que Redis tenía hasta 2024 y lo gobierna una fundación con participación de varias empresas, entre ellas grandes proveedores cloud. Por eso AWS, Google Cloud, DigitalOcean u OVHcloud lo ofrecen gestionado. Para vosotros, el efecto práctico es que suele ser la opción por defecto en sus servicios de caché.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el