Pgvector vs base de datos vectorial: cuándo su Postgres ya le basta
Si ya tiene Postgres en producción, probablemente no necesite una base de datos vectorial dedicada para empezar con RAG: la extensión pgvector más el full-text search nativo de Postgres cubren la mayoría de catálogos de hasta unos cientos de miles de fragmentos. La migración a un motor dedicado (Qdrant, Weaviate, Milvus) tiene sentido cuando el volumen, la latencia exigida o el aislamiento multi-tenant lo justifican, no antes.
Dos piezas distintas, no una sola decisión
La confusión habitual es tratar "búsqueda vectorial" y "búsqueda en Postgres" como si fueran mutuamente excluyentes. En realidad son dos capacidades complementarias que Postgres ya ofrece por separado desde hace años.
Full-text search: el motor de palabras clave que ya tiene
Postgres incluye desde siempre un motor de búsqueda de texto completo basado en el tipo tsvector y en índices GIN. Permite tokenizar, aplicar stemming por idioma (incluido el español), ponderar campos y ordenar resultados con ts_rank. Es rápido, maduro y no requiere ninguna extensión adicional. Su punto débil es el de cualquier buscador léxico puro: si el usuario pregunta "cómo anular un pedido" y el documento dice "cancelación de compra", el full-text clásico no siempre hace el salto semántico.
Pgvector: similitud semántica dentro de la misma base de datos
pgvector añade un tipo de columna `vector` y operadores de distancia (`<->` para euclídea, `<=>` para coseno, `<#>` para producto interno negativo) para comparar embeddings. Soporta búsqueda exacta y, a partir de ciertos volúmenes, índices aproximados IVFFlat y HNSW para acelerar las consultas a costa de un pequeño margen de recall. La ventaja central es que el vector vive en la misma fila que el resto de metadatos del documento: no hay que sincronizar dos sistemas ni preocuparse de que un chunk se borre en un lado y quede huérfano en el otro.
Qué significa "aproximado" en la práctica
Un índice HNSW no garantiza encontrar siempre el vecino más cercano exacto, sino uno muy próximo con alta probabilidad. Para la mayoría de casos de RAG esa pérdida de precisión es imperceptible, pero construir el índice consume memoria y CPU de forma notable cuanto mayor es el catálogo.
Cuándo Postgres más pgvector le basta
En la práctica, esta combinación resuelve bien la inmensa mayoría de proyectos de una pyme, un despacho o un equipo de producto que está empezando con RAG.
- Su catálogo tiene hasta unos cientos de miles de fragmentos (chunks), no decenas de millones.
- Ya opera Postgres en producción y su equipo conoce SQL mejor que una API vectorial nueva.
- La latencia aceptable para una consulta es de unos cientos de milisegundos, no de 10-20 ms bajo carga masiva.
- Necesita joins reales entre el resultado de la búsqueda y otras tablas (usuarios, permisos, facturación).
- El presupuesto de infraestructura es ajustado y añadir un servicio gestionado adicional no compensa.
- Quiere mantener un único punto de backup, réplica y copia de seguridad.
Casi todos los proveedores de Postgres gestionado (Supabase, Neon, Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL) ya incluyen la extensión pgvector lista para activar con un simple `CREATE EXTENSION`. Eso reduce bastante la fricción operativa de empezar.
Cuándo conviene una base de datos vectorial dedicada
Hay escenarios donde pgvector empieza a notar el esfuerzo y un motor diseñado específicamente para vectores da un margen de maniobra que Postgres no ofrece sin trabajo extra.
- Volumen de decenas o cientos de millones de vectores con necesidad de reindexado continuo sin bloquear escrituras.
- Latencia estricta (sub-20 ms en p99) con alta concurrencia de consultas.
- Multi-tenant con aislamiento fuerte entre colecciones y necesidad de escalar particiones de forma independiente.
- Filtrado por metadatos muy complejo combinado con búsqueda vectorial a gran escala, con planificadores de consulta optimizados para ese patrón.
- Equipos que ya han agotado la capacidad vertical de su instancia de Postgres y prefieren escalar horizontalmente una pieza aislada.
Si está en ese punto, merece la pena revisar las alternativas disponibles, incluidas las que no dependen de un único proveedor. Tiene un repaso detallado en Alternativas a Pinecone para equipos pequeños, y una visión más amplia de cómo encaja cada pieza del stack en El stack RAG open source en 2026.
Comparativa operativa
Postgres + pgvector vs base de datos vectorial dedicada
| Criterio | Postgres + pgvector | Base de datos vectorial dedicada |
|---|---|---|
| Volumen cómodo | Hasta cientos de miles de chunks | Millones a cientos de millones |
| Latencia típica | Decenas a cientos de ms | Single-digit a bajos ms bajo carga |
| Filtrado por metadatos | Excelente (SQL nativo, joins) | Bueno, pero con su propio lenguaje de filtros |
| Mantenimiento | Uno más en el Postgres que ya opera | Un servicio nuevo que monitorizar y actualizar |
| Coste inicial | Bajo, reutiliza infraestructura existente | Añade coste de licencia o infraestructura dedicada |
| Backup y HA | Hereda el de Postgres | Depende del motor, a veces menos maduro |
| Escalado horizontal | Limitado, requiere sharding manual | Pensado para ello desde el diseño |
El verdadero objetivo no es elegir vectores o palabras clave: es la búsqueda híbrida
Tanto si se queda en Postgres como si migra a un motor dedicado, el error más caro no es la elección de base de datos sino quedarse solo con búsqueda semántica o solo con full-text. Las consultas reales de los usuarios mezclan términos exactos (códigos de producto, nombres propios, referencias legales) con intenciones conceptuales, y ningún enfoque puro cubre ambas bien. Combinar el ranking de ts_rank con la distancia de pgvector mediante una fusión de resultados (por ejemplo, reciprocal rank fusion) suele dar mejores respuestas que cualquiera de los dos métodos por separado. Lo explicamos con detalle, incluidos los casos donde falla cada enfoque, en Búsqueda híbrida: por qué combinar palabras clave y vectores gana a cualquiera de las dos por separado.
La calidad de los resultados también depende de cómo trocea los documentos antes de indexarlos: un chunking demasiado grande diluye la señal vectorial, uno demasiado pequeño rompe el contexto necesario para que el full-text encuentre coincidencias útiles. Tiene una guía práctica en Estrategias de chunking para RAG.
Checklist para decidir sin dar vueltas
- ¿Cuántos fragmentos (chunks) espera tener dentro de 12 meses, no hoy?
- ¿Qué latencia p99 exige realmente su caso de uso (chat interactivo vs proceso por lotes)?
- ¿Necesita cruzar el resultado de la búsqueda con permisos, facturación u otras tablas relacionales?
- ¿Su equipo tiene capacidad para operar un servicio adicional, o prefiere un único sistema que respaldar?
- ¿El proveedor de Postgres que usa ya soporta pgvector con índices HNSW de forma gestionada?
- ¿Ha medido ya el coste total, no solo el de cómputo? Revise ¿Cuánto cuesta realmente un sistema RAG? y Precio de una base de datos vectorial: qué paga realmente antes de decidir.
Si prefiere no operar ninguna de las dos piezas
Hay un tercer camino que muchos equipos pequeños pasan por alto: no gestionar ni Postgres con pgvector ni un motor vectorial dedicado, sino subir los documentos a una base de conocimiento ya indexada. En Kopik puede crear una base de conocimiento gratis subiendo PDF, Word, texto o Markdown desde /dashboard/bases/new: el sistema extrae el texto, lo trocea y lo indexa con búsqueda híbrida (full-text más expansión semántica) sin que tenga que decidir entre IVFFlat o HNSW ni dimensionar un clúster. Puede consultar la base desde la web, por API con claves propias o desde un servidor MCP usable en Claude, Cursor o ChatGPT. Si en algún momento quiere comparar motores gestionados antes de montar el suyo, el catálogo de bases públicas le da una idea rápida de cómo responden distintos corpus.
Compruebe si su caso cabe sin infraestructura nueva
Suba sus documentos a Kopik y obtenga búsqueda híbrida lista para consultar en minutos, antes de decidir si necesita pgvector o un motor vectorial dedicado.
Preguntas frecuentes
Preguntas frecuentes
¿Pgvector es tan rápido como una base de datos vectorial dedicada?
Con índices HNSW bien dimensionados, pgvector ofrece latencias razonables para catálogos de hasta cientos de miles de vectores. A partir de decenas de millones y con alta concurrencia, los motores dedicados suelen mantener latencias más bajas y estables porque están optimizados exclusivamente para ese patrón de acceso.
¿Cuántos vectores soporta pgvector antes de degradarse?
No hay un límite duro, pero el rendimiento empieza a notarse según crece el índice y la memoria disponible. Para la mayoría de proyectos de una pyme (cientos de miles de chunks) funciona con normalidad; a partir de varios millones conviene medir latencias reales antes de confiar en el valor por defecto.
¿Necesito índices HNSW o IVFFlat en pgvector?
Para catálogos pequeños, una búsqueda exacta sin índice aproximado puede ser suficiente. En cuanto el volumen crece y las consultas se ralentizan, HNSW suele dar mejor recall que IVFFlat a cambio de más consumo de memoria durante la construcción del índice.
¿Puedo combinar full-text y vectores en la misma consulta SQL de Postgres?
Sí. Puede lanzar ambas búsquedas por separado (una con tsvector y ts_rank, otra con el operador de distancia de pgvector) y fusionar los resultados en la capa de aplicación, o combinarlas en una sola consulta SQL con una puntuación ponderada entre ambos rankings.
¿Cuándo debería migrar de pgvector a un vector store dedicado?
Cuando el volumen de vectores, la concurrencia o la necesidad de reindexado en caliente empiecen a degradar la latencia de su Postgres de forma medible, o cuando necesite escalar la capa vectorial de forma independiente del resto de su base de datos relacional.
Reciba la newsletter de Kopik
Nuevas bases de conocimiento, guías sobre RAG y novedades del producto. Un correo cada una o dos semanas, baja con un clic.
Al suscribirse, acepta recibir nuestra newsletter. Nunca compartimos su dirección.