Milvus: la base vectorial de los grandes volumes

#Lo que busca Milvus

La mayoría de las bases de datos vectoriales están orientadas a proyectos de equipo. Milvus apunta a la escala industrial: separación del almacenamiento y el cómputo, escalabilidad horizontal nativa en Kubernetes y un catálogo de índices que permite ajustar con precisión el equilibrio entre precisión, memoria y velocidad. El proyecto afirma que puede procesar decenas de miles de consultas sobre miles de millones de vectores y mantener los datos al día mediante actualizaciones en streaming en tiempo real. Es una elección de arquitectura, no un simple conjunto de funciones.

Esta ambición tiene una contrapartida directa: en un corpus de cincuenta mil pasajes, esta potencia no se nota, pero la complejidad sí se nota de inmediato. Por tanto, la pregunta que hay que plantearse no es «¿es la mejor base de datos vectorial?», sino «¿alcanzará mi corpus el tamaño en el que estas decisiones importen?».

El proyecto se presenta como una base en la que confían los desarrolladores de IA para construir aplicaciones de búsqueda de texto e imágenes, generación aumentada por recuperación y sistemas de recomendación, y afirma que numerosas empresas lo utilizan para usos considerados críticos. Este posicionamiento permite entender a qué público se dirige: equipos que construyen un producto destinado a crecer, no un script personal de búsqueda documental entre unos cientos de archivos PDF.

#Una arquitectura basada en componentes

En un despliegue completo, Milvus no es un proceso, sino un conjunto: nodos de consulta, nodos de datos, un servicio de coordinación, almacenamiento de objetos y un registro de mensajes. Cada componente se dimensiona de forma independiente —el proyecto destaca la posibilidad de aumentar por separado los nodos de consulta para una carga de lectura intensa y los nodos de datos para una carga de escritura intensa—, lo que es exactamente lo que se busca a gran escala y aquello de lo que se prescinde en una estación de trabajo. Los microservicios sin estado en Kubernetes también permiten una recuperación rápida tras un incidente, y la compatibilidad con réplicas mejora aún más la tolerancia a fallos al cargar los segmentos de datos en varios nodos de consulta. Esta separación entre cómputo y almacenamiento es precisamente lo que distingue una base de datos pensada para la escala industrial de una pensada para un único servicio: tiene un coste de operación permanente, incluso cuando el tráfico sigue siendo bajo, algo que pocas comparativas mencionan antes del despliegue.

#Mínimo en Python, con Milvus Lite

1. 01
   Conectarse

   La secuencia from pymilvus import MilvusClient seguida de client = MilvusClient("milvus_demo.db") abre una base de datos local en un archivo; sustituir el argumento por una URI de servidor permite pasar a un despliegue completo sin modificar el resto del código.
2. 02
   Crear una colección

   client.create_collection(collection_name="demo_collection", dimension=1024) — la dimensión debe coincidir exactamente con la de tu modelo de embedding.
3. 03
   Insertar los datos

   res = client.insert(collection_name="demo_collection", data=data) donde data es una lista de diccionarios, cada uno con un vector y sus metadatos.
4. 04
   Buscar

   res = client.search(collection_name="demo_collection", data=vecteurs_requete, limit=5, output_fields=["text"]) devuelve los cinco pasajes más cercanos con los campos solicitados.

El proyecto destaca su integración con herramientas de IA comunes —LangChain, LlamaIndex, OpenAI, Hugging Face—, lo que, según sus autores, convierte a Milvus en un almacén vectorial adecuado para la generación aumentada por recuperación. Milvus funciona con modelos de embedding tanto de código abierto como a través de servicios de embedding, para texto, imágenes y vídeo, y ofrece una utilidad (pymilvus[model]) para convertir datos no estructurados en vectores sin que tengas que escribir el código de llamada al modelo ni gestionar por separado la biblioteca cliente de cada proveedor.

#Los índices, y cuál elegir

En un corpus documental local, la mayoría de las veces basta con recordar una sola cifra: por debajo del millón de vectores, la diferencia entre las seis familias de índices se mide en milisegundos, no en minutos, y casi siempre sería mejor invertir en otra parte del proyecto el esfuerzo dedicado a elegir el ajuste adecuado.

El consejo que más tiempo ahorra sigue siendo el mismo en todas partes: empezar por la búsqueda exacta. Los índices aproximados resuelven un problema de escala, y adoptarlos antes de tener ese problema supone añadir parámetros que ajustar y una exhaustividad que medir, a cambio de milisegundos que nadie ha notado. Milvus documenta explícitamente estas seis familias —HNSW, IVF, FLAT, SCANN, DiskANN y variantes cuantizadas— como optimizadas cada una para un escenario diferente, con soporte de GPU mediante CAGRA de NVIDIA para la indexación de volúmenes muy grandes. El proyecto añade a estos índices un filtrado por metadatos y una búsqueda por rango optimizados al mismo nivel que la propia búsqueda vectorial, en lugar de implementarlos como una capa separada que ralentizaría el resultado final.

#Lo que distingue a Milvus a gran escala

Más allá de los índices, varias funcionalidades explican por qué grandes organizaciones eligen Milvus en lugar de una alternativa más sencilla. La arquitectura multi-tenant permite configurar cuatro niveles de aislamiento —base de datos, colección, partición o clave de partición—, lo que permite a un solo clúster atender desde unas pocas decenas hasta millones de tenants sin perder rendimiento de búsqueda ni granularidad en el control de acceso. El almacenamiento en caliente y en frío coloca los datos consultados con frecuencia en memoria o en SSD, y relega los datos consultados rara vez a un almacenamiento más lento y menos costoso, lo que reduce la factura sin sacrificar el rendimiento de las tareas críticas.

En cuanto a la búsqueda, Milvus admite de forma nativa la búsqueda de texto completo con BM25, así como embeddings dispersos aprendidos como SPLADE y BGE-M3, además de la búsqueda semántica mediante vectores densos. Los vectores dispersos y densos pueden coexistir en una misma colección, con funciones de reordenación (reranking) para fusionar los resultados de varias consultas —una búsqueda híbrida similar en esencia a la que ofrece Qdrant, pero construida aquí en torno a BM25 en lugar de una fusión genérica de puntuaciones—. En cuanto a la seguridad, el proyecto destaca la autenticación obligatoria, el cifrado TLS de las comunicaciones y el control de acceso por roles (RBAC), tres elementos que se esperan cuando una base de datos sirve a varias aplicaciones o equipos, y mucho menos críticos para una instancia que solo escuche en localhost.

#En local: lo que implica

Recursos

El despliegue completo requiere varios contenedores y varios gigabytes de memoria RAM, incluso antes de añadir tu modelo de lenguaje: el servicio de coordinación, los nodos de consulta, los nodos de datos, el almacenamiento de objetos y el registro de mensajes se ejecutan por separado.

Memoria de vectores

Alrededor de 4 kB por vector de 1.024 dimensiones en precisión completa, sin contar el índice. Es esta aritmética la que determina la arquitectura, no las funcionalidades, y sigue siendo válida tanto si usas Milvus como Qdrant o pgvector.

Operación

Copias de seguridad, actualizaciones de versión, supervisión: una verdadera base de datos distribuida requiere un verdadero administrador. El ecosistema Milvus incluye Attu, una interfaz gráfica de administración, y Birdwatcher para depuración del sistema, dos herramientas que aun así suponen conocer la arquitectura subyacente.

La GPU queda reservada para el modelo

La codificación de documentos y la inferencia ya compiten por la tarjeta; la búsqueda vectorial, en cambio, es principalmente cuestión de procesador y memoria, salvo que se active explícitamente la construcción de índices en la GPU mediante CAGRA para volúmenes muy grandes.

#Cuándo Milvus es la opción adecuada

La pregunta adecuada nunca es «¿qué base de datos tiene más funcionalidades?», sino «¿cuáles de estas funcionalidades utilizará realmente mi proyecto?». La arquitectura multi-tenant de cuatro niveles, el almacenamiento en caliente y en frío, el RBAC y la búsqueda híbrida BM25 existen para organizaciones que atienden a miles de usuarios con requisitos de cumplimiento normativo; en un ordenador personal o para las herramientas internas de un equipo pequeño, estos mecanismos permanecen inactivos, mientras que la complejidad de su configuración sigue muy presente. Milvus se justifica cuando la trayectoria del proyecto —no su estado actual— apunta hacia esas necesidades en un plazo razonable.

• Qdrant: el servicio dedicado más sencillo de usar
• pgvector: mantenerse en PostgreSQL
• FAISS: la biblioteca, no el servicio
• Secuencia RAG completa en Python
• El kit RAG local QuelLLM
• Fuente: repositorio oficial Milvus en GitHub
• Fuente: documentación oficial de Milvus Lite
• Fuente: descripción general de la arquitectura distribuida de Milvus

#FAQ