¿Dónde guardo los vectores de mi búsqueda semántica?
Qdrant vs pgvector vs Weaviate vs Chroma
La pregunta correcta no es cuál es más rápido, sino cuántas bases de datos quieres mantener.
Los cuatro guardan vectores y buscan por similitud. Con menos de un millón de fragmentos, los cuatro son rápidos y el argumento del rendimiento es marketing.
Lo que de verdad cambia el proyecto es si añades un sistema nuevo a tu infraestructura o si reutilizas el que ya tienes. Una base de datos más es una copia de seguridad más, un puerto más y una cosa más que se cae un domingo.
Las opciones
pgvector
Extensión de PostgreSQL: vectores dentro de la base que ya tienes
Tu dato: Depende del motor que le pongas
- Cuándo gana
- Casi siempre en pyme. Cero infraestructura nueva, tus copias de seguridad ya lo cubren y puedes cruzar el vector con tus tablas en la misma consulta.
- Cuándo pierde
- Por encima de unos millones de vectores empieza a necesitar ajuste fino de índices.
Qdrant
Base vectorial dedicada, escrita en Rust, fácil de autoalojar
Tu dato: Depende del motor que le pongas
- Cuándo gana
- Volúmenes grandes, filtrado complejo por metadatos y cuando la búsqueda es el corazón del producto.
- Cuándo pierde
- Es un servicio más que mantener, respaldar y vigilar.
Weaviate
Base vectorial con módulos de vectorización y esquema propio
Tu dato: Depende del motor que le pongas
- Cuándo gana
- Si quieres que la propia base genere los embeddings y te ahorre esa capa.
- Cuándo pierde
- Más opinionada: su esquema condiciona cómo modelas los datos.
Chroma
La más sencilla: empotrable, pensada para prototipar
Tu dato: No sale de tu casa
- Cuándo gana
- Prototipos, pruebas de concepto y cuadernos. De cero a funcionando en minutos.
- Cuándo pierde
- No la queremos en producción con datos que importen.
Cara a cara
| Criterio | pgvector | Qdrant | Weaviate | Chroma |
|---|---|---|---|---|
| Tu dato | No sale si es tu Postgres | No sale autoalojado | No sale autoalojado | No sale |
| Infraestructura nueva | Ninguna | Un servicio más | Un servicio más | Ninguna |
| Hasta 1M de fragmentos | De sobra | De sobra | De sobra | Justo |
| Más de 10M | Con ajuste | Cómodo | Cómodo | No |
| Filtros por metadatos | SQL completo | Muy bueno | Bueno | Básico |
| Copias de seguridad | Las que ya tienes | Aparte | Aparte | Aparte |
| Producción | Sí | Sí | Sí | No |
Qué elegiríamos nosotros
pgvector, salvo que tengas una razón concreta para lo contrario. Si ya usas PostgreSQL —y casi todo el mundo lo usa— no añadas un sistema entero para guardar vectores: tus copias, tu monitorización y tu equipo ya saben tratarlo, y puedes filtrar por cliente, fecha o permiso en la misma consulta. Salta a Qdrant cuando los volúmenes o el filtrado lo justifiquen, no antes. Chroma solo para prototipar.
Cuándo no elegir ninguna
Si tu documentación son treinta páginas, no necesitas búsqueda vectorial: cabe entera en el contexto del modelo y te ahorras toda esta capa.
¿Y en tu caso concreto?
Ninguna comparativa sabe cuántos usuarios tienes, qué dato mueves ni quién lo va a mantener. Cuéntanoslo y te decimos cuál de estas —o ninguna.