Garnet de Microsoft: alternativa de caché de alto rendimiento

Actualizado: 2026-05-03

Microsoft Research abrió el código de Garnet en marzo de 2024 con una promesa poco modesta: un servidor de caché 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 asíncrona del sistema operativo como piezas centrales. Casi veinte meses después, con varias versiones estables y despliegues públicos en servicios internos de Microsoft, toca hacer una valoración honesta de dónde está el proyecto, qué aporta realmente y en qué casos compensa considerarlo frente a Redis u otras alternativas como Valkey.

Puntos clave

• Garnet está escrito en .NET 8 con múltiples hilos con afinidad a núcleos y un backend de almacenamiento llamado Tsavorite que gestiona memoria y disco de forma híbrida.
• La compatibilidad con el protocolo Redis es la decisión estratégica más importante: cualquier cliente Redis existente puede conectar a Garnet sin cambios.
• Según benchmarks publicados por Microsoft, Garnet sostiene entre dos y tres veces más operaciones por segundo que Redis en máquinas con muchos núcleos; benchmarks de terceros confirman números parecidos con matices.
• El ecosistema alrededor de Garnet es inmaduro: herramientas de observabilidad, clientes especializados, operadores de Kubernetes e integraciones con proveedores de nube son escasos.
• Para la mayoría de equipos pequeños y medianos, Valkey o Redis siguen siendo la respuesta razonable en 2025; Garnet entra cuando has agotado las alternativas simples y necesitas ese siguiente escalón de rendimiento sin pasar a cluster.

Qué es y de dónde sale

Garnet nació como proyecto de investigación dentro del grupo de sistemas de Microsoft Research. El punto de partida fue una observación concreta: Redis, pese a ser excelente, fue escrito cuando los servidores tenían cuatro núcleos y 16 GB de memoria, y su arquitectura de hilo único aprovecha mal las máquinas actuales con 64 o 128 núcleos y cientos de gigabytes. Redis resuelve parcialmente el problema mediante clustering, pero un solo proceso Redis sigue siendo incapaz de saturar una máquina grande.

Garnet se escribió para explotar ese hardware: usa múltiples hilos con afinidad a núcleos, un backend de almacenamiento llamado Tsavorite que gestiona memoria y disco de forma híbrida, y primitivas de entrada y salida asíncrona cuando el sistema operativo las ofrece.

La compatibilidad con el protocolo de Redis es la decisión estratégica más importante del proyecto. Cualquier cliente Redis existente puede conectar a Garnet sin cambios. No es una startup buscando financiación, es un laboratorio industrial que publica código.

Los números publicados por Microsoft son agresivos: según sus propios benchmarks, Garnet sostiene entre dos y tres veces más operaciones por segundo que Redis en una máquina con muchos núcleos. Los benchmarks de terceros en 2025 han confirmado números parecidos con matices, como suele pasar.

Arquitectura: lo que hace distinto a Garnet

La pieza técnica más interesante es el motor de almacenamiento Tsavorite, evolución del proyecto de investigación anterior llamado FASTER. Tsavorite puede funcionar puramente en memoria como Redis, pero también en modo híbrido memoria más disco gestionando un espacio de direcciones mayor que la memoria física 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 único, Garnet tiene un planificador interno que reparte peticiones entre hilos con afinidad a núcleos. Para cargas donde las peticiones son independientes, esta arquitectura aprovecha los 32 o 64 núcleos de un servidor moderno de una forma que Redis simplemente no puede.

El tercer diferenciador es el soporte nativo para almacenamiento persistente y replicación. Garnet incluye replicación asíncrona primario-secundario con conmutación por fallo, similar a Sentinel pero integrada, y persistencia mediante checkpoints del almacén Tsavorite.

Comparación con Redis y Valkey

La comparación relevante en 2025 no es solo con Redis sino también con Valkey, el fork abierto que nació cuando Redis cambió su licencia en marzo de 2024. Valkey ha mantenido la compatibilidad API y licencia abierta, se usa ya por defecto en AWS ElastiCache y tiene respaldo de la Linux Foundation.

• Valkey es la opción conservadora: protocolo Redis idéntico, arquitectura de hilo único evolucionada. Su rendimiento es comparable al de Redis 7, quizás ligeramente mejor, pero no pretende ser una revolución arquitectónica.
• Dragonfly, el otro contendiente serio, es más parecido a Garnet en ambición pero diferente en implementación: está escrito en C++, usa un modelo de múltiples hilos sin compartir estado entre ellos.
• Garnet ocupa un sitio propio: rendimiento muy alto en hardware grande, arquitectura distinta de los anteriores, respaldo de un laboratorio de investigación industrial, y el hecho diferencial de estar escrito en .NET. Esto último 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.

Dónde compensa considerarlo

Hay tres escenarios donde Garnet merece evaluación seria:

1. Cuando necesitas un caché de muy alto rendimiento en una máquina grande y Redis monolítico 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 núcleos puede cubrir la carga.
2. Cuando tu plataforma ya está en .NET y quieres reducir la superficie de tecnologías. Operar un servicio .NET y un Redis implica dos ecosistemas distintos de monitorización, despliegue y personal.
3. Cuando el caso de uso se acerca a base de datos más que a caché pura: conjuntos de datos mayores que la memoria, necesidad de durabilidad, requisito de replicación integrada.

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 e integraciones con proveedores de nube son escasos.
• El soporte del protocolo Redis no es completo al cien por cien. Las operaciones más usadas están cubiertas, pero comandos menos frecuentes y algunas estructuras de datos avanzadas tienen implementaciones parciales o ausentes. Antes de migrar una aplicación compleja hay que auditar qué comandos usa.
• La curva operacional: Garnet en .NET implica un runtime con características propias: ajuste de recolector de basura, gestión de memoria gestionada, comportamiento bajo presión.

Cómo pensar la decisión

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, documentación acumulada durante quince años, integraciones en cada plataforma.

Para la mayoría de equipos pequeños y medianos, la respuesta razonable en 2025 sigue siendo Valkey si quieres abierto y compatible, o Redis si ya estás cómodo con la licencia. Garnet entra como opción a considerar cuando has agotado las alternativas simples y necesitas ese siguiente escalón de rendimiento sin pasar a cluster.

Saber cuándo aplica es más valioso que decidir a priori si te gusta más o menos que las alternativas.

Conclusión

Garnet es una herramienta especializada entre varias, no el Redis del futuro. Ocupa bien un nicho concreto: cargas muy grandes en máquinas únicas, entornos .NET puros y casos con necesidad de durabilidad e híbrido memoria-disco. Fuera de ese nicho, las opciones más maduras siguen siendo mejores elecciones.