Tras cubrir Chroma como opción para prototipos y pgvector como solución sobre PostgreSQL, toca hablar de las bases de datos vectoriales dedicadas que escalan más allá. En 2023 las tres opciones más adoptadas son Qdrant, Pinecone y Weaviate. Cada una tiene fortalezas distintas y la elección correcta depende del caso.
Qdrant
Qdrant es probablemente la opción open-source más popular para producción seria en 2023.
Arquitectura:
- Escrito en Rust — performance y consumo de memoria predecibles.
- Index HNSW por defecto, con quantization opcional (scalar, product, binary).
- Soporta payloads (metadatos) ricos con filtrado eficiente integrado en la búsqueda.
- Modo cliente-servidor o cluster distribuido con sharding y replicación.
Fortalezas:
- Filtros junto con búsqueda vectorial muy bien resueltos — aplica el filtro durante el algoritmo HNSW, no después.
- Self-hosted gratis o managed pagado (Qdrant Cloud).
- Performance excepcional en benchmarks públicos de QPS y latencia.
- API clara, SDKs en Python, JavaScript, Go, Rust.
Limitaciones:
- Operación distribuida (cluster) requiere conocimiento — no es trivial.
- Comunidad menor que Pinecone en cuanto a tutoriales y blogs.
Es la opción que recomendaría por defecto para 2024 si quieres open source con futuro y no te asusta operar tu propio servicio.
Pinecone
Pinecone es la opción managed-only: no puedes ejecutarla tú; consumes su servicio cloud.
Arquitectura:
- 100% SaaS — no tienes acceso al binario ni opción de self-host.
- Algoritmo propio de indexado (no es HNSW puro). Auto-tunado por el servicio.
- Replicación, escalado y operaciones gestionadas por Pinecone.
Fortalezas:
- Cero operación. Crea un índice y úsalo. Ideal para equipos sin infra dedicada.
- Escalado automático transparente.
- API muy estable y documentada, ecosistema maduro de tutoriales.
- Adopción amplia — fácil contratar gente que la conoce.
Limitaciones:
- Coste: para volumen alto, el precio escala rápido. Una pod de tamaño moderado son cientos de dólares al mes.
- Lock-in: tu pipeline depende del servicio. Migrar implica re-vectorizar y re-cargar todo en otra solución.
- Sin self-host: para datos sensibles o regulados puede ser show-stopper.
- Funcionalidad de filtrado menos rica que Qdrant o Weaviate (pero suficiente para casos típicos).
Pinecone es la elección correcta cuando “no quiero pensar en operar una BD vectorial” tiene más peso que el coste.
Weaviate
Weaviate es la opción más feature-rich de las tres.
Arquitectura:
- Open source, escrito en Go.
- Self-hosted o managed (Weaviate Cloud).
- Schema-based: defines clases con propiedades tipadas, similar a una BD documental.
- Generación de embeddings opcional integrada (vectoriza texto al insertar usando módulos pluggable: OpenAI, HuggingFace, Cohere).
- Hybrid search nativo (vector + BM25 keyword).
Fortalezas:
- Búsqueda híbrida nativa muy bien implementada — combina vector y keyword en una sola query.
- Multi-tenancy sólido para SaaS multi-cliente.
- Generative search: integra LLMs directamente para devolver respuestas generadas, no solo documentos.
- GraphQL como API — interesante si tu equipo ya consume GraphQL.
Limitaciones:
- Más conceptos a aprender (schema, modules, references). La curva es más empinada.
- Performance en HNSW puro a veces algo inferior a Qdrant (depende del benchmark).
- Operar a escala requiere atención (cluster, backups, recovery).
Weaviate es la opción correcta cuando necesitas búsqueda híbrida real o multi-tenancy serio.
Comparativa práctica
| Aspecto | Qdrant | Pinecone | Weaviate |
|---|---|---|---|
| Self-host | Sí | No | Sí |
| Managed | Sí | Sí (única opción) | Sí |
| Lenguaje | Rust | Propietario | Go |
| Filtros vectoriales | Excelentes | Buenos | Excelentes |
| Búsqueda híbrida | Limitada | Limitada | Nativa |
| Multi-tenant | Sí | Sí | Excelente |
| Coste a escala | Bajo (self) | Alto | Bajo (self) |
| Curva aprendizaje | Suave | Mínima | Media |
| Comunidad | Creciente | Grande | Sólida |
Cómo elegir
Un árbol de decisión razonable para 2024:
- No quiero operar nada, presupuesto OK: Pinecone.
- Quiero open source con buen rendimiento, operación razonable: Qdrant.
- Necesito búsqueda híbrida o multi-tenant complejo: Weaviate.
- Empiezo a explorar y no sé el tamaño final: Chroma → migrar después.
- Ya tengo Postgres y mi corpus es <10M: pgvector → quizá nunca migres.
La buena noticia: las APIs son suficientemente similares que migrar entre ellas es factible si tu lógica RAG está bien encapsulada. Estructura el código con un retriever abstracto desde el día uno y reduce el coste de cambiar.
Lo que importa más que la elección
Después de varios proyectos, observo que la elección de BD vectorial importa menos de lo que parece para la calidad final del RAG. Lo que más impacta:
- Calidad del corpus. Documentos sucios producen retrieval malo independientemente de la BD.
- Estrategia de chunking. Un mal chunking hunde cualquier BD.
- Modelo de embedding. Diferencias notables entre OpenAI ada-002, BGE y similares.
- Re-ranking post-retrieval con un modelo cross-encoder. A menudo mejora más que cambiar de BD.
- Diseño del prompt que recibe el contexto recuperado.
Optimiza esos cinco puntos antes de obsesionarte con la elección entre Qdrant y Pinecone.
Conclusión
Las bases vectoriales dedicadas son una pieza importante del stack moderno LLM. Cada una de las tres principales tiene casos donde brilla. La elección correcta depende más de tus prioridades operativas (self-host vs managed, coste vs simplicidad) que de diferencias técnicas profundas. Empieza con la opción que mejor encaje con tu equipo y migra solo si encuentras un cuello de botella concreto.
Síguenos en jacar.es para más sobre arquitectura RAG, vector databases y construcción de productos LLM.
