Redis 8.2 y su soporte vectorial: cuándo tiene sentido
Actualizado: 2026-07-07
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.0 la búsqueda vectorial dejó de vivir en un módulo aparte y pasó a formar parte del núcleo abierto de Redis (Redis Open Source); en 8.2 se sumó SVS-VAMANA, un índice vectorial con compresión, junto a mejoras de rendimiento.
-
En su propio benchmark, Redis reporta hasta 4 veces menos latencia bajo carga concurrente que Qdrant y hasta 9,5 veces más rendimiento que pgvector sobre Aurora PostgreSQL; son cifras publicadas por el fabricante, léelas con esa cautela.
-
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 persistidos en disco de Qdrant o Milvus se imponen sobre el índice enteramente en RAM de Redis.
-
HNSW no soporta bien las eliminaciones masivas: un ritmo de borrado alto fragmenta el grafo y obliga a reconstruir el índice completo de vez en cuando.
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 la costumbre de comportarse de forma distinta según la versión exacta del módulo cargada. En 8.0, Redis fusionó Redis Stack y Redis Community Edition en una sola distribución (Redis Open Source) e integró RediSearch, con su búsqueda vectorial, sin necesidad de módulos aparte. En 8.2 llegó SVS-VAMANA, un nuevo tipo de índice vectorial con compresión pensado para reducir la huella de memoria del HNSW, además de una lista larga de mejoras de rendimiento documentadas en las notas de versión.
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 mismo 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: lo que dicen los propios fabricantes
Aquí conviene ser honesto sobre la fuente: los números de rendimiento más citados vienen del propio Redis, y Qdrant publica los suyos por su lado, así que ninguno de los dos es un árbitro neutral. Dicho esto, ambos benchmarks son reproducibles y usan datasets públicos, lo que al menos permite verificarlos.
Redis, en su benchmark de bases de datos vectoriales[1], se compara contra Qdrant 1.7.4, Milvus 2.4.1 y Weaviate 1.25.1 sobre datasets como gist-960-euclidean (1 millón de vectores, 960 dimensiones) y dbpedia-openai-1M-angular (1 millón de vectores, 1.536 dimensiones), y reporta hasta 3,4 veces más consultas por segundo que Qdrant y hasta 4 veces menos latencia bajo carga concurrente, a igualdad de recall. Contra Aurora PostgreSQL 16.1 con pgvector 0.5.1, Redis reclama hasta 9,5 veces más rendimiento y hasta 9,7 veces menos latencia. Qdrant, por su parte, publica sus propios benchmarks[2] donde su motor logra el mayor número de consultas por segundo y la menor latencia en casi todos los escenarios que prueba, incluido frente a Redis.
Mi lectura, con esa reserva por delante: la diferencia es real pero no de un orden de magnitud en la mayoría de los casos, y 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.
Diagrama de flujo GraphRAG que muestra la relación entre embeddings, búsqueda vectorial y generación augmentada, el caso de uso que Redis 8.2 atiende en corpus de tamaño medio
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: solo los vectores en bruto, sin contar el grafo, ya piden aproximadamente 4 bytes por dimensión y por vector (float32). Haz la cuenta con un corpus de 50 millones de vectores a 768 dimensiones y salen del orden de 150 GB de RAM, antes de sumar el propio grafo HNSW. Qdrant y Milvus soportan índices persistidos a disco con capa de caché caliente, lo que permite servir corpus grandes en máquinas mucho más modestas.
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. Cuanto más alta es la cardinalidad del filtro, más nota el planificador de Redis que tiene menos información sobre la selectividad real que un motor pensado desde el origen para búsquedas filtradas.
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: en su propio benchmark contra pgvector sobre Aurora PostgreSQL, Redis reporta tiempos de indexado entre 5,5 y 19 veces más rápidos. Para corpus que se reconstruyen a diario, esa velocidad de ingesta importa tanto como la de consulta.
La pega es que HNSW no soporta bien las eliminaciones masivas. La mayoría de implementaciones hacen borrado suave: marcan el vector como eliminado en vez de sacarlo del grafo, y las consultas siguen atravesando esos nodos "fantasma" hasta que alguien reconstruye el índice. Cuanto mayor es el ritmo de borrado, antes hay que reconstruir para no perder recall. Redis no expone todavía una operación de reconstrucción incremental, así que en la práctica el patrón que funciona es reconstruir el índice completo por lotes. 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 o tres 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 la mayor parte de lo que ya funciona. Para un equipo de quince personas con SRE dedicado, esta ventaja se diluye bastante.
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 arrastraba desde que RediSearch sumó búsqueda vectorial en 2022. Con el índice integrado en el núcleo abierto, Redis pasa a competir en serio con pgvector en la franja media de corpus, y eso es 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.
La versión en inglés de este artículo está disponible en Redis 8.2 and its vector support: when it actually makes sense.
