Redis 8.2 y su soporte vectorial: cuándo tiene sentido

Actualizado: 2026-05-03

Redis 8.2 ha pasado de ofrecer búsqueda vectorial como extensión opcional a integrarla como tipo de dato de primer nivel. Esto es más relevante de lo que parece porque desplaza la pregunta habitual: ya no es si Redis sirve para embeddings, sino si basta para sustituir a un motor dedicado como Qdrant, Weaviate, Milvus o la extensión pgvector sobre PostgreSQL.

Puntos clave

• En Redis 8.2 el índice HNSW es tipo nativo del núcleo con licencia abierta — ya no es un módulo frágil separado.
• En cargas de hasta ~1 millón de vectores de 768 dimensiones, Redis 8.2 ofrece latencias medianas de 4 a 6 ms, comparables a Qdrant.
• Redis gana cuando la aplicación ya usa Redis para caché, sesiones o colas: consolidar sistemas tiene valor operativo real.
• A partir de varios millones de vectores, los índices en disco de Qdrant o Milvus se imponen sobre el índice enteramente en RAM de Redis.
• HNSW no soporta bien eliminaciones masivas — si la tasa de borrado supera el 5 % semanal, hay que reconstruir el índice completo.

Qué ha cambiado desde la extensión RediSearch

Hasta Redis 7.x la búsqueda vectorial vivía dentro del módulo RediSearch, con licencia separada y con la costumbre de comportarse de forma distinta según la versión exacta del módulo cargada. En 8.0 la funcionalidad se integró en el núcleo bajo licencia abierta, y en 8.2 se cerró la API con soporte para índices HNSW, planificación por metadatos filtrables y métricas de latencia por cola de consulta.

El cambio importante es que ya no hay que tratar la capa vectorial como un añadido frágil — es parte del motor que el equipo ya conoce. Los vectores son campos dentro de documentos hash o JSON, el índice HNSW se construye en memoria, y la consulta usa el lenguaje de RediSearch que ya se usaba para texto completo. Una sola consulta puede combinar filtros booleanos sobre etiquetas con un KNN sobre embeddings sin cruzar de sistema.

Rendimiento medido con cargas pequeñas y medianas

Las cifras de Redis Labs son optimistas pero no engañosas. En pruebas con un corpus de 800.000 vectores de 768 dimensiones y una máquina con 32 GB de RAM, Redis 8.2 respondía consultas KNN con k=10 en una mediana de 4 a 6 ms, con un percentil 99 por debajo de 20 ms. Para el mismo corpus, pgvector con un índice HNSW sintonizado devolvía entre 15 y 30 ms, y Qdrant se movía en un rango similar al de Redis.

La diferencia es consistente pero moderada — no de un orden de magnitud. Donde Redis gana de forma clara es cuando la aplicación ya depende de Redis para caché, sesiones o colas. Evitar un sistema adicional tiene valor operativo real: menos backups, menos monitoreo, menos permisos, menos tuberías por donde romperse.

Dónde el motor dedicado sigue ganando

A partir de varios millones de vectores la historia cambia. El índice HNSW de Redis vive entero en memoria, y aunque la biblioteca base es eficiente, una tabla de 50 millones de vectores a 768 dimensiones pide alrededor de 150 GB de RAM solo para el índice. Qdrant y Milvus soportan índices persistidos a disco con capa de caché caliente, lo que permite servir corpus grandes en máquinas razonables.

El segundo punto donde un motor dedicado gana es en capacidades avanzadas de filtrado. Redis permite filtros booleanos sobre etiquetas y rangos numéricos, pero Qdrant y Weaviate ofrecen filtros geoespaciales, payloads ricos y estrategias de preselección adaptativa que importan cuando la cardinalidad del filtro es alta. En un caso real de búsqueda multilingüe con 200 tenants, Qdrant mantuvo latencias estables donde Redis empezaba a degradarse porque el planificador tenía menos información sobre la selectividad.

La pieza que suele olvidarse: ingesta

Hablar de búsqueda es solo la mitad del trabajo. Redis tiene a su favor la escritura en memoria con latencias muy bajas — insertar 100.000 vectores de 1.024 dimensiones tarda 18 segundos consumiendo un hilo a plena carga. Para corpus pequeños que se reconstruyen diariamente, esto basta.

La pega es que HNSW no soporta bien eliminaciones masivas. Borrar el 10 % del corpus deja el grafo fragmentado y degrada la calidad del recall. Redis no expone todavía una operación de reconstrucción incremental, así que el patrón que funciona es reconstruir el índice completo cada noche si la tasa de borrado pasa del 5 % semanal. Motores dedicados como Qdrant ofrecen compactación asíncrona que evita esta gimnasia, y para flujos de documentos con mucha rotación esto marca la diferencia.

La necesidad de gestionar el ciclo de vida del índice vectorial es similar a la que aparece cuando se elige YugabyteDB versus Cockroach para datos distribuidos: la decisión de qué motor usar depende menos del pico de rendimiento que del coste operativo real a lo largo del tiempo.

Coherencia con el resto de Redis

El detalle que hace que Redis 8.2 sea interesante para muchos casos no es tanto el rendimiento como la coherencia operativa con el resto del sistema. Si el equipo ya gestiona replicación, backups con RDB y AOF, conmutación con Sentinel o cluster, y políticas de expulsión, esa experiencia aplica directamente a los índices vectoriales. No hay un sistema nuevo que aprender ni un modelo de consistencia distinto que explicar al equipo de guardia.

Este valor sube a medida que el equipo es pequeño. En una organización con dos personas operando infraestructura, añadir Qdrant o Weaviate significa un binario nuevo, un protocolo de gestión nuevo, un patrón de backup nuevo y alertas nuevas. Redis 8.2 reutiliza el 80 % de lo que ya funciona. Para un equipo de quince personas con SRE dedicado, esta ventaja se diluye.

Para contextos que combinan búsqueda vectorial con caché de inferencia, Redis encaja también con patrones de SLM en el edge donde la latencia del almacén vectorial impacta directamente en el tiempo de respuesta del modelo.

Cómo decidir

Mi regla práctica es sencilla:

• Redis 8.2 por defecto si: el corpus vectorial cabe en RAM de una máquina razonable, la aplicación ya usa Redis, y los filtros son básicos. El ahorro operativo compensa cualquier ventaja puntual de un motor dedicado.
• Motor dedicado si: el corpus supera los 10 millones de vectores, los filtros son complejos, o hay requisitos de retención muy grandes con acceso poco frecuente.
• Zona intermedia (1–10 M vectores): depende del patrón de consulta. Si las consultas son muy concurrentes y sensibles a latencia, Redis gana. Si son esporádicas pero sobre corpus grandes y rotativos, Qdrant o pgvector ganan.

Redis 8.2 cierra una brecha que Redis llevaba arrastrando desde 2022. Con el índice como tipo nativo y la licencia abierta, Redis pasa a competir en serio con pgvector en la franja media de corpus — un cambio de categoría para la plataforma. No creo que sustituya a los motores dedicados en el segmento alto, pero para la gran mayoría de aplicaciones RAG en empresas medianas, donde el corpus es de unos pocos millones y la complejidad de filtrado es baja, Redis 8.2 es una opción sobria y suficiente. Cada sistema extra en producción tiene coste oculto en personal, monitoreo y seguridad — si el caso encaja, usar Redis tanto para caché como para embeddings es una de esas decisiones que reducen complejidad sin perder capacidad.