Qdrant, Weaviate y Milvus: código abierto de producción

Tercera entrega del bloque de plataformas. Cuando PostgreSQL se queda corto y el gestionado no encaja, quedan los motores dedicados de código abierto. Son tres los que importan, y aunque hacen lo mismo, no encajan con los mismos equipos.

Un motor dedicado hace una sola cosa: almacenar vectores con sus metadatos y responder consultas de vecinos más próximos con filtros. Todo lo demás —el texto original, los usuarios, la lógica de negocio— vive en otra parte. Ese enfoque tiene una ventaja evidente, que es que cada decisión de diseño está optimizada para el caso de uso, y una desventaja igual de evidente: es un sistema más que operar, sincronizar y respaldar.

Los tres candidatos comparten mucho. Los tres son de código abierto con empresa detrás y oferta gestionada, los tres usan HNSW como índice principal, los tres ofrecen filtrado integrado en el recorrido del grafo, los tres tienen cuantización y los tres funcionan. Las diferencias están en la arquitectura, en el modelo de despliegue y en cuánto tienes que saber para operarlos.

Qdrant

Escrito en Rust, con una arquitectura deliberadamente simple: un solo proceso que se ejecuta como binario o como contenedor, con almacenamiento local y una API REST y gRPC. No hay dependencias externas, ni servicio de coordinación, ni cola de mensajes, ni almacén de objetos. Se arranca y funciona.

Su punto fuerte es el filtrado. Fue diseñado desde el principio para consultas con condiciones sobre metadatos y su motor de filtrado es expresivo: condiciones anidadas, rangos, geolocalización, pertenencia a listas, campos anidados en documentos. La ejecución decide dinámicamente entre recorrer el índice con el filtro aplicado o hacer búsqueda exhaustiva sobre el subconjunto, según la cardinalidad estimada del filtro. Es la implementación correcta del criterio 2 de la entrega 28.

Ofrece cuantización escalar, por producto y binaria, con la opción de mantener los vectores originales en disco y los cuantizados en memoria, reordenando los mejores candidatos con los originales. Ese patrón reduce mucho la memoria necesaria con una pérdida de recall pequeña.

El clúster existe —hay reparto y replicación—, pero es la parte menos madura del producto y la que más atención exige. En modo de nodo único es extraordinariamente estable y sencillo.

Weaviate

Escrito en Go, también de proceso único en su despliegue básico, pero con una filosofía distinta: no es sólo un almacén de vectores, sino una base de datos con esquema y con módulos que integran el resto del pipeline.

La diferencia práctica más visible es que Weaviate puede vectorizar por ti. Configuras un módulo de embeddings —comercial o local— y le entregas texto: él llama al modelo, guarda el vector y, en consulta, vectoriza la pregunta. Ahorra código y crea acoplamiento; si cambias de modelo de embeddings, cambias la configuración del motor, no tu aplicación. Hay módulos equivalentes para reranking y para generación, de modo que se puede montar un RAG casi entero dentro del motor.

Tiene un esquema explícito con clases, propiedades y referencias entre objetos, lo que da una estructura de datos más rica que una simple colección de vectores con metadatos. La búsqueda híbrida es nativa y de primera clase: una consulta con un parámetro que pondera la parte densa y la léxica.

El coste de todo eso es una curva de aprendizaje más larga. Hay que entender el esquema, los módulos, la configuración de cada uno y su API, que ha cambiado de forma notable entre versiones mayores. Es el motor que más te da y el que más te pide leer.

Milvus

Es el más ambicioso de los tres y el que se diseñó desde el principio para escala grande. Su arquitectura separa por completo cómputo y almacenamiento, y separa además los tipos de cómputo entre sí: hay nodos de consulta, nodos de datos, nodos de índice y un nodo coordinador, apoyados en un almacén de objetos para los datos, una cola de mensajes para el registro de escrituras y un servicio de metadatos.

Eso permite escalar cada parte de forma independiente y llegar a volúmenes que los otros dos no alcanzan con comodidad: miles de millones de vectores es su territorio declarado. También significa que un despliegue completo de Milvus son varios sistemas distribuidos funcionando a la vez, con todo lo que eso implica en observabilidad, actualizaciones y depuración.

El proyecto es consciente y ofrece dos escalones más bajos: una versión embebida para pruebas locales y un modo autónomo en un solo contenedor. Son perfectamente usables, pero conviene entender que empezar en el modo pequeño y crecer al grande no es cambiar un parámetro: es cambiar de arquitectura de despliegue.

Es también el motor con más variedad de índices: además de HNSW, ofrece familias IVF, índices sobre disco de tipo DiskANN y variantes para vectores binarios. Si tienes un caso donde el índice importa de verdad, aquí hay más donde elegir.

Tabla comparativa

Las escalas son órdenes de magnitud con hardware razonable y sin cuantización agresiva; con cuantización binaria y reordenación, los tres suben un escalón.

Qué encaja con cada perfil de equipo

Con la comparativa delante, la recomendación se puede decir sin ambages.

Equipo pequeño, sin especialista en infraestructura, que necesita un motor dedicado por filtrado o por escala: Qdrant. Es el que menos te va a pedir. Un contenedor, un volumen persistente, una API clara y un modelo de filtrado que cubre lo que un RAG con permisos necesita. En nodo único aguanta mucho más de lo que la mayoría de proyectos van a exigirle, y el día que no aguante, migrar desde ahí es un problema conocido.

Equipo que quiere reducir código propio y acepta acoplarse al motor: Weaviate. Si la idea es tener el menor pipeline posible en tu aplicación y dejar que el motor se encargue de vectorizar, buscar en híbrido y reordenar, es la opción que más trabajo te quita. El precio es que tu arquitectura queda definida por sus módulos, y que las migraciones entre versiones mayores han sido trabajo real.

Equipo con plataforma consolidada y volumen grande: Milvus. Si ya operas Kubernetes con almacenamiento distribuido, colas y observabilidad, la complejidad arquitectónica de Milvus deja de ser un problema y su capacidad de escalar cada componente por separado se convierte en una ventaja concreta. Si no tienes esa plataforma, Milvus en clúster te va a consumir más tiempo del que el proyecto de RAG merece.

Lo que no cambia al elegir uno u otro

Tres avisos para cerrar.

El primero, el de siempre: cambiar de motor no mejora la calidad de la recuperación. Los tres devuelven prácticamente los mismos vecinos ante los mismos vectores y los mismos parámetros, porque los tres implementan el mismo algoritmo. La diferencia entre ellos es operativa, no de calidad de resultados.

El segundo: al salir de PostgreSQL pierdes las transacciones entre tus datos y tus vectores. A partir de ahora, insertar un documento son dos escrituras en dos sistemas que pueden fallar por separado, y hace falta un mecanismo —reintentos, cola, reconciliación periódica— para que el índice y la fuente no se desincronicen. Es trabajo que antes no existía y que hay que presupuestar.

El tercero: la oferta gestionada de cada uno de estos tres proyectos existe y es una opción legítima. Usar Qdrant Cloud o Weaviate Cloud te da el motor sin la operativa, y sin la dependencia total de un formato propietario, porque el mismo software se puede levantar en tu infraestructura si un día decides irte. Es un punto intermedio que la entrega siguiente examina con detalle.

Qué viene ahora

La siguiente entrega se ocupa de los servicios totalmente gestionados: Pinecone y los vectoriales integrados en bases de datos que quizá ya usas, como Atlas Vector Search, Elasticsearch o Redis. Qué compras exactamente cuando pagas, cómo está estructurado el precio, y qué implica en dependencia de proveedor, coste de salida y residencia de los datos.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.