Valkey: el mejor sustituto directo de código abierto para Redis
En marzo de 2024, Redis Inc. pasó de su licencia BSD permisiva a RSALv2/SSPLv1, creando una exposición real al cumplimiento para los equipos de ingeniería comercial.
En respuesta, la comunidad de OSS y de usuarios bifurcó casi de inmediato Redis en una nueva opción llamada Valkey. Lanzado el mismo mes bajo la Linux Foundation, Valkey ofrece un verdadero sustituto directo que evita la carga legal introducida por Redis.
Sustituya Redis sin reconstruir sus aplicaciones
La respuesta de las comunidades a las funcionalidades de cambio de licencia de Redis fue buscar opciones rápidas, coordinadas y con buenos recursos, principalmente una bifurcación de las comunidades. Valkey no es una bifurcación de protesta con poco apoyo. Valkey se beneficia de un respaldo y apoyo institucional sustanciales y de un desarrollo activo; por lo tanto, es una alternativa con licencia BSD completa con total compatibilidad con la base de código de Redis que la mayoría de los equipos ya están ejecutando.
Valkey: Tranquilidad integrada en el proyecto y el servicio
![[object Object]](https://assets.ovhcloud.com/1fiLCdLm2rnpzzL64g7Ebupwy_sN2JmNTk4MzJkMDY1NjMw/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_96bcf0ea.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fihA7kvoqCdjbpFh8CSqrAFg_sODM3OGYwNzczYjJhNGI5/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_a2fe1080.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fi4ELnwoChAbqnnwm3zvgAv5_sODJhOTlmMGI0OTUzYWJl/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_f9914d17.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiz8uqm8kwozpmrpt2nCdg5F_sNzRjNjI0Y2U4ZDlmOWQ0/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_fe1d1635.svg){kind=small}
Por qué los desarrolladores buscan una alternativa a Redis en 2026
El cambio de licencia de Redis de 2024 explicado
Durante la mayor parte de su existencia, Redis se distribuyó bajo la licencia BSD de 3 cláusulas, una de las licencias de código abierto más permisivas. Podía usar, modificar y crear productos comerciales sobre Redis sin restricciones. Eso cambió el 20 de marzo de 2024, cuando Redis Inc. anunció que Redis 7.4 y todas las futuras versiones con nuevas funcionalidades pasarían a un modelo de doble licencia: RSALv2 (Redis Source Available License v2) y SSPLv1 (Server Side Public License). Ninguna de las dos licencias está aprobada por la Open Source Initiative (OSI), y ambas imponen restricciones explícitas sobre cómo se puede utilizar el software en entornos comerciales y en la nube.
Por qué la SSPL crea un riesgo de cumplimiento para los productos comerciales
La SSPL fue redactada originalmente por MongoDB para evitar que los proveedores de la nube ofrecieran servicios de bases de datos gestionados sin contribuir a cambio. El problema principal para los equipos de productos comerciales es la Sección 13: si su aplicación se pone a disposición como servicio y depende de software con licencia SSPL, es posible que se le exija publicar el código fuente de todo su stack de servicios, incluidos los componentes propietarios que haya desarrollado.
Para la mayoría de los equipos de ingeniería, esa obligación es inviable al desarrollar funcionalidades y alternativas. Incluso cuando el asesoramiento legal determina que el riesgo es bajo en la práctica, la incertidumbre por sí sola crea fricción con las adquisiciones, las revisiones de seguridad y los contratos de clientes empresariales. La RSALv2 agrava esto al prohibir explícitamente el uso en productos o funcionalidades de la competencia, dando a Redis Inc. una amplia discreción sobre lo que constituye competencia... dejando de nuevo a los usuarios de Redis expuestos a un campo de minas legal de desafíos legales, desafíos que se evitan fácilmente utilizando códigos regidos por una licencia aprobada por la OSI en su lugar.
Permanecer en Redis 7.2: la deuda de seguridad oculta
La última versión de almacenamiento en caché de Redis bajo BSD fue la 7.2. Algunos equipos eligen quedarse en esa versión, en lugar de aceptar los nuevos términos de licencia. Es, posiblemente, una decisión pragmática a corto plazo que conlleva un coste a largo plazo. Redis 7.2 ya no recibe parches de seguridad de búsqueda ni correcciones de errores de Redis Inc., lo que significa que cualquier CVE descubierto después del cambio de licencia queda sin abordar en esa rama. Para los equipos que ejecutan el almacenamiento en caché de Redis 7.2 en un entorno de producción, que manejan datos confidenciales o que operan bajo marcos como NIS2 o SOC 2, este no es un riesgo teórico. Mantenerse en Redis 7.2 crea una brecha de cumplimiento activa que se amplía con cada mes que pasa.
Por qué la AGPLv3 para Redis 8.0 no es una tercera opción
Con el lanzamiento de Redis 8.0 en 2025, Redis Inc. realizó otro movimiento de licencias, esta vez a la AGPLv3, que está aprobada por la OSI. Es un paso adelante genuino en términos de legitimidad de código abierto, y aborda una de las críticas principales dirigidas al cambio de 2024. Sin embargo, la AGPLv3 es una licencia copyleft fuerte, y presenta sus propias complicaciones para los equipos comerciales.
Cualquier software que interactúe con un componente con licencia AGPLv3 a través de una red puede activar el requisito de publicar el código fuente de ese software bajo la misma licencia. Para los productos SaaS propietarios, esto sigue siendo una limitación importante para las alternativas. Varias voces destacadas en la industria, incluidos los colaboradores del proyecto Valkey, han señalado que la AGPLv3 (aunque está más basada en principios que la SSPL) todavía coloca a Redis en una categoría diferente a la de las alternativas de código abierto verdaderamente permisivas.
Preservar el comportamiento de la aplicación y controlar la ubicación de los datos
Los diseños multinodo también pueden preservar patrones de resiliencia familiares. La compatibilidad sigue requiriendo pruebas. Los módulos, el comportamiento específico de la versión y las combinaciones de comandos inusuales pueden producir una respuesta diferente. El diseño del almacenamiento, los parámetros del cliente y la topología también pueden afectar a la estabilidad o a la velocidad. Ninguna migración debe asumir que todos los casos extremos se ejecutarán más rápido o se comportarán de forma idéntica. La licencia de Valkey, aprobada por la OSI, ofrece a los equipos comerciales una alternativa a Redis de código abierto duradera sin vincular la arquitectura de la aplicación a términos restrictivos.
La elección de la implementación añade entonces una dimensión operativa. Una oferta europea gestionada puede combinar el procesamiento por hilos, la colocación resiliente de nodos y el alojamiento controlado de datos. Este enfoque respalda la soberanía de los datos europea al mantener visibles la ubicación, el acceso y la gestión contractual, al mismo tiempo que reduce la administración rutinaria de la plataforma.
DragonflyDB lidera en velocidad bruta de nodo único en algunas pruebas, pero esa ventaja se reduce significativamente en configuraciones de clúster. La paridad de funciones con Redis 7.2 es completa, y la hoja de ruta de Valkey ha añadido desde entonces mejoras de subprocesamiento múltiple y ganancias de eficiencia de memoria que, en algunas cargas de trabajo, lo sitúan por delante de la versión de la que se bifurcó.
Otras tecnologías pueden adaptarse a requisitos especializados, como la búsqueda vectorial o las cargas de trabajo sin servidor intermitentes. La investigación puede incluir material técnico encontrado a través de Google, debates en la comunidad y documentación de proveedores, pero la documentación primaria y las pruebas controladas deberían tener mayor peso. Compare cada alternativa según el cambio de aplicación, la madurez operativa, el soporte disponible, la gobernanza y el esfuerzo total de migración. La tecnología adecuada es aquella que cumple los requisitos medidos con una licencia y un riesgo operativo aceptables.
Adapte el modelo operativo a sus requisitos
Valkey gestionado
Las Databases for Valkey gestionadas se adaptan a las empresas que desean operaciones sencillas y costes de infraestructura predecibles. OVHcloud gestiona la alta disponibilidad, el mantenimiento, la supervisión y las copias de seguridad, reduciendo el trabajo interno necesario para ejecutar un servicio resiliente. El ancho de banda y las IOPS incluidos también hacen que la elaboración de presupuestos sea más clara. Esta es una opción predeterminada práctica cuando los equipos de plataforma necesitan Valkey sin tener que ocuparse de todas las tareas operativas.
Valkey autogestionado
La autogestión proporciona control sobre las versiones del software, la topología, los parámetros de seguridad y la ubicación de la implementación. Puede encajar en empresas con requisitos específicos u operaciones de base de datos establecidas. Los inconvenientes son igualmente reales: el equipo interno es responsable de los aumentos de la carga, las copias de seguridad, la observabilidad, las pruebas de failover y la respuesta ante incidentes. Los recursos de la comunidad ayudan, pero no sustituyen al soporte de producción responsable ni a la capacidad operativa.
KeyDB
KeyDB puede adaptarse a equipos que investiguen la ejecución multihilo para cargas de trabajo de datos en memoria particulares y objetivos de latencia. Evalúe la compatibilidad, la actividad de lanzamiento, el estado del proyecto y el soporte disponible antes de comprometerse. Evalúe la aplicación real en lugar de asumir que una característica arquitectónica mejorará todos los patrones de solicitud. La información asociada a un fundador o a una declaración inicial del proyecto también debe contrastarse con la documentación actual.
Alternativas especializadas
Los servicios sin servidor pueden reducir la planificación de la capacidad para cargas de trabajo intermitentes, mientras que las bases de datos vectoriales admiten la búsqueda por similitud y otros modelos de datos especializados. El software alternativo en memoria puede dirigirse a necesidades específicas de velocidad o persistencia. Estas herramientas pueden resolver problemas definidos, pero no son necesariamente opciones de sustitución directa. Tenga en cuenta los cambios en la aplicación, el movimiento de datos, la propiedad operativa y el coste a largo plazo antes de seleccionarlas frente a Valkey.
Elija una ruta de migración que se ajuste al tiempo de inactividad
Detenga su instancia de Redis para garantizar la coherencia, copie el archivo en su directorio de datos de Valkey, inicie Valkey y habrá terminado. El tiempo total de migración es proporcional al tamaño del conjunto de datos, no a la complejidad de la aplicación. Para entornos de producción donde el tiempo de inactividad no es aceptable, la replicación en vivo es la ruta más segura. Valkey puede configurarse como una réplica de una instancia de Redis 7.2 en ejecución utilizando el comando estándar REPLICAOF.
Una vez que la réplica esté totalmente sincronizada, actualice la cadena de conexión de su aplicación para que apunte a Valkey, promuévala a principal y retire la instancia de Redis. Dado que ambos sistemas utilizan el mismo protocolo de replicación, este proceso es limpio y ha sido bien probado en producción por equipos de todos los principales proveedores de nube.
![[object Object]](https://assets.ovhcloud.com/1fiX676v6wSp4t82zXEm6hhry_sNzAzOTNmMTIyZWVkYzg0/555a10a6-71ae-4d77-959e-b2a8dc0e9831_ima_c8d0550b.png)
Construya un marco de preparación para la migración de cuatro partes
1. Compatibilidad de aplicaciones
Cree un inventario de cada comando, biblioteca de cliente y versión de protocolo en uso. Registre las funcionalidades de RESP3, scripts Lua, transacciones, patrones pub/sub, dependencias de JSON o módulos, y el comportamiento de tiempo de espera específico de la aplicación. Un core compatible no demuestra que cada extensión se comporte de la misma manera. Compare el entorno actual con la versión de destino y pruebe solicitudes representativas. Incluya el manejo de fallos, la agrupación de conexiones y la lógica de reintento. Si una aplicación depende de tecnología suministrada por un complemento externo, compruebe su estado de mantenimiento por separado. Este inventario convierte la compatibilidad general en evidencia basada en requisitos específicos.
2. Proteja la integridad de los datos
Mida el conjunto de datos antes de la migración, incluyendo recuentos de claves, distribución de caducidad, tamaños de objetos y consumo máximo de memoria. El destino necesita suficiente memoria para el funcionamiento normal, la replicación y la sobrecarga temporal durante la sincronización o la persistencia. Revise los parámetros de snapshot y de solo anexión en lugar de copiarlos sin análisis. Tras la transferencia, compare los recuentos de claves, los valores muestreados y el comportamiento de caducidad. Las comprobaciones a nivel de aplicación pueden revelar problemas que los totales brutos pasan por alto, como sesiones mal formadas o estados de cola incompletos. Comparta los criterios de aceptación con los propietarios del servicio antes de la migración para que todos utilicen la misma definición de un conjunto de datos válido.
3. Mapee la topología de destino
Documente si la plataforma actual es independiente, replicada o distribuida a través de un clúster. Registre cada nodo, ruta de red, regla de seguridad, dependencia de DNS y ubicación física. Este mapa ayuda a los equipos a seleccionar un layout objetivo que refleje las necesidades de resiliencia en lugar de reproducir elecciones históricas. Las pruebas de conectividad deben cubrir la aplicación, los sistemas de monitorización y las herramientas administrativas. Para una carga de trabajo distribuida, compruebe el manejo de ranuras, la colocación de réplicas y el comportamiento durante la pérdida de nodos. Los requisitos de ubicación de los datos también pueden determinar qué regiones o zonas de disponibilidad son aceptables.
4. Controle la migración
Establezca líneas base de latencia, tasa de errores y recursos antes de mover el tráfico. Defina los umbrales de monitorización, los criterios de reversión y los responsables de la toma de decisiones mientras el servicio sea estable. Esto evita que los equipos debatan sobre el comportamiento aceptable durante un incidente. Desvíe el tráfico por etapas cuando la arquitectura lo permita. Empiece con cargas de trabajo internas o de bajo riesgo, observe los errores del cliente y compare los resultados, y luego aumente la proporción. Mantenga el origen recuperable hasta que se complete la validación. Una migración segura depende de pruebas medidas, una propiedad clara y una ruta de reversión, no solo de afirmaciones de compatibilidad.
¿Por qué elegir OVHcloud Managed Databases for Valkey?
Una de las frustraciones persistentes con las bases de datos gestionadas en la nube es la imprevisibilidad de la factura. Piense en cargos que se disparan bajo carga porque el ancho de banda, las IOPS y el almacenamiento de copias de seguridad se miden por separado. El modelo de precios de OVHcloud agrupa estos costes en una tarifa mensual fija. El ancho de banda, las operaciones de E/S y las copias de seguridad automatizadas están incluidos, por lo que el coste que ve al realizar el aprovisionamiento es el coste que paga en producción. Para los equipos financieros y de compras en empresas en expansión que gestionan presupuestos de infraestructura ajustados, esto hace que la planificación de la capacidad sea significativamente más clara.
