Microsoft Research abrio el codigo de Garnet en marzo de 2024 con una promesa poco modesta: un servidor de cache clave valor compatible con el protocolo de Redis, pero con rendimiento significativamente superior en hardware moderno gracias a una arquitectura escrita desde cero en .NET con el conjunto de hilos y la maquinaria asincrona del sistema operativo como piezas centrales. Casi veinte meses despues, con varias versiones estables y despliegues publicos en servicios internos de Microsoft, toca hacer una valoracion honesta de donde esta el proyecto, que aporta realmente y en que casos compensa considerarlo frente a Redis u otras alternativas como Valkey.
Que es y de donde sale
Garnet nacio como proyecto de investigacion dentro del grupo de sistemas de Microsoft Research. El punto de partida fue una observacion concreta: Redis, pese a ser excelente, fue escrito cuando los servidores tenian cuatro nucleos y 16 GB de memoria, y su arquitectura de hilo unico aprovecha mal las maquinas actuales con 64 o 128 nucleos y cientos de gigabytes. Redis resuelve parcialmente el problema mediante clustering, pero un solo proceso Redis sigue siendo incapaz de saturar una maquina grande. Garnet se escribio para explotar ese hardware: usa multiples hilos con afinidad a nucleos, un backend de almacenamiento llamado Tsavorite que gestiona memoria y disco de forma hibrida, y primitivas de entrada y salida asincrona cuando el sistema operativo las ofrece.
La compatibilidad con el protocolo de Redis es la decision estrategica mas importante del proyecto. Cualquier cliente Redis existente, desde el oficial hasta las librerias de lenguajes, puede conectar a Garnet sin cambios. Esto le da un ecosistema instantaneo que otros proyectos como KeyDB o Dragonfly tambien aprovechan, pero Garnet llega con el respaldo de un equipo de investigacion grande y publicaciones academicas que documentan sus tecnicas. No es una startup buscando financiacion, es un laboratorio industrial que publica codigo.
Los numeros publicados por Microsoft son agresivos: segun los propios puntos de referencia, Garnet sostiene entre dos y tres veces mas operaciones por segundo que Redis en una maquina con muchos nucleos, con latencias de percentil 99 similares o mejores. Los puntos de referencia de terceros en 2025 han confirmado numeros parecidos aunque con matices, como suele pasar. La diferencia de rendimiento es real, pero depende mucho del patron de carga y del tamano de los valores.
Arquitectura: lo que hace distinto a Garnet
La pieza tecnica mas interesante es el motor de almacenamiento Tsavorite, evolucion del proyecto de investigacion anterior llamado FASTER. Tsavorite es un almacen clave valor de proposito general que puede funcionar puramente en memoria como Redis, pero tambien en modo hibrido memoria mas disco gestionando un espacio de direcciones mayor que la memoria fisica disponible. Esto es relevante porque permite que un solo servidor maneje conjuntos de datos que no caben en RAM sin saltar a un nodo adicional.
La segunda pieza es la concurrencia. Mientras Redis serializa todo el trabajo en un hilo unico y deja al sistema operativo multiplexar conexiones, Garnet tiene un planificador interno que reparte peticiones entre hilos con afinidad a nucleos. Cada conexion se asocia a un hilo y las operaciones se procesan sin contencion dentro de ese hilo. Para cargas donde las peticiones son independientes, esta arquitectura aprovecha los 32 o 64 nucleos de un servidor moderno de una forma que Redis simplemente no puede.
El tercer diferenciador es el soporte nativo para almacenamiento persistente y replicacion. Garnet incluye replicacion asincrona primario secundario con conmutacion por fallo, similar a Sentinel pero integrada, y persistencia mediante checkpoints del almacen Tsavorite. La operacion es mas parecida a una base de datos que a un cache, y aunque la mayoria de casos de uso de Garnet son de cache puro, estar preparado para cargas con requisito de durabilidad amplia el espacio de aplicacion.
Comparacion con Redis y Valkey
La comparacion relevante en 2025 no es solo con Redis sino tambien con Valkey, el tenedor abierto que nacio cuando Redis cambio su licencia en marzo de 2024. Valkey ha mantenido la compatibilidad API y licencia abierta, se usa ya por defecto en AWS ElastiCache como opcion recomendada, y tiene respaldo de la Linux Foundation. La batalla por el sucesor del Redis clasico tiene varios contendientes, y cada uno ocupa un nicho distinto.
Valkey es la opcion conservadora: protocolo Redis identico, arquitectura de hilo unico evolucionada, y la ventaja de que cualquier equipo con operacion Redis pre-2024 puede migrar sin aprender nada nuevo. Su rendimiento es comparable al de Redis 7, quizas ligeramente mejor por algunas optimizaciones recientes, pero no pretende ser una revolucion arquitectonica.
Dragonfly, el otro contendiente serio, es mas parecido a Garnet en ambicion pero mas distinto en implementacion: esta escrito en C++, usa un modelo de multiples hilos sin compartir estado entre ellos, y su rendimiento bruto en hardware grande es comparable al de Garnet. El ecosistema Dragonfly ha crecido significativamente en 2024-2025 y tiene mas despliegues publicos documentados.
Garnet ocupa un sitio propio: rendimiento muy alto en hardware grande, arquitectura distinta de los anteriores, respaldo de un laboratorio de investigacion industrial, y el hecho diferencial de estar escrito en .NET. Esto ultimo es doble filo: para equipos que ya viven en el ecosistema .NET, Garnet es nativamente integrable y auditable; para equipos que no, supone introducir una dependencia de runtime significativa que otros productos no exigen.
Donde compensa considerarlo
Hay tres escenarios donde Garnet merece evaluacion seria. El primero es cuando necesitas un cache de muy alto rendimiento en una maquina grande y Redis monolitico no basta. En lugar de saltar a un cluster Redis con la complejidad operativa que eso implica, un solo nodo Garnet en un servidor con 32 o 64 nucleos puede cubrir la carga. Esto simplifica significativamente la arquitectura y reduce el coste total de operacion.
El segundo es cuando tu plataforma ya esta en .NET y quieres reducir la superficie de tecnologias. Operar un servicio .NET y un Redis implica dos ecosistemas distintos de monitorizacion, despliegue y personal. Un Garnet integrado en la misma infraestructura reduce esa fragmentacion. En organizaciones grandes de Microsoft esto fue probablemente una de las motivaciones del proyecto, y para empresas con stack similar puede ser relevante.
El tercero es cuando el caso de uso se acerca a bases de datos mas que a cache pura: conjuntos de datos mayores que la memoria, necesidad de durabilidad, requisito de replicacion integrada. Aqui Garnet empieza a competir con bases embebidas como LMDB o incluso con Postgres en ciertos nichos, y su arquitectura hibrida memoria disco le da ventajas que Redis no tiene.
Limitaciones y cautelas
No todo es favorable. El ecosistema alrededor de Garnet es inmaduro comparado con Redis. Herramientas de observabilidad, clientes especializados, operadores de Kubernetes, integraciones con proveedores de nube y libros de experiencia operativa son escasos. Si se rompe algo un sabado por la noche, la comunidad que puede ayudar es minuscula frente a la de Redis.
La segunda cautela es que el soporte del protocolo Redis no es completo al cien por cien. Las operaciones mas usadas estan cubiertas, pero comandos menos frecuentes y algunas estructuras de datos avanzadas tienen implementaciones parciales o ausentes. Antes de migrar una aplicacion compleja hay que auditar que comandos usa y verificar cobertura caso por caso.
La tercera es operacional. Garnet en .NET implica un runtime con caracteristicas propias: ajuste de recolector de basura, gestion de memoria gestionada, comportamiento bajo presion. Operadores acostumbrados a Redis en C con su gestion manual de memoria tienen que reaprender patrones de diagnostico. No es malo, pero es una curva real.
Como pensar la decision
Mi lectura tras seguir el proyecto desde el inicio es que Garnet no va a desplazar a Redis en el corto plazo, y probablemente tampoco en el medio. Redis y Valkey tienen demasiada inercia: ecosistema, personal formado, documentacion acumulada durante quince anos, integraciones en cada plataforma. Lo que puede hacer Garnet es ocupar nichos donde sus ventajas arquitectonicas justifican la curva: cargas muy grandes en maquinas unicas, entornos .NET puros, casos con necesidad de durabilidad e hibrido memoria disco.
Para la mayoria de equipos pequenos y medianos, la respuesta razonable en 2025 sigue siendo Valkey si quieres abierto y compatible, o Redis si ya estas comodo con la licencia. Garnet entra como opcion a considerar cuando has agotado las alternativas simples y necesitas ese siguiente escalon de rendimiento sin pasar a cluster. Esa es una posicion legitima y el proyecto la ocupa bien, pero no es el Redis del futuro; es una herramienta especializada entre varias, y saber cuando aplica es mas valioso que decidir a priori si te gusta mas o menos que las alternativas.
