¿Necesitas una base de datos vectorial dedicada? En 2026, casi nunca
Si estás montando RAG o búsqueda semántica en tu producto, la respuesta corta es esta: para la mayoría de aplicaciones por debajo de ~10-20 millones de vectores, no necesitas una base de datos vectorial dedicada. pgvector sobre el Postgres que probablemente ya tienes es el punto de partida correcto en 2026. Añadir Pinecone, Qdrant o Weaviate desde el día uno suele ser complejidad que pagas antes de tiempo y que casi nunca recuperas.
La decisión no es "Postgres o base de datos vectorial", sino en qué momento tu caso concreto cruza el umbral en el que un motor dedicado empieza a compensar. Este artículo es ese marco de decisión: qué ha cambiado en pgvector, dónde está el techo real y qué señales te dicen que ha llegado el momento de migrar.
El problema real (y por qué se sobredimensiona)
Un sistema de RAG necesita tres cosas: convertir texto en embeddings, guardarlos, y recuperar los más parecidos a una consulta mediante búsqueda de vecinos aproximados (ANN). El marketing de las bases de datos vectoriales se centra en ese último paso como si fuera un problema exótico que solo un motor especializado puede resolver.
En la práctica, para volúmenes normales, la latencia de tu RAG no está dominada por la búsqueda vectorial, sino por la generación del embedding y la llamada al LLM. En un índice de 1M de vectores, una consulta HNSW en pgvector responde en el orden de 5-8 ms; el total hasta devolver resultados ronda los 300 ms, y ese presupuesto se lo come sobre todo la API de embeddings. Optimizar una base de datos vectorial dedicada para ganar milisegundos en un paso que ya es marginal es optimizar la parte equivocada.
Qué ha cambiado en pgvector
Parte del reflejo de "necesito algo dedicado" viene de comparar con un pgvector de hace dos años. La extensión ha madurado:
- Índices HNSW con builds paralelos y mejor gestión de memoria (serie 0.7+), que acercan el rendimiento a los motores especializados en el rango de millones de vectores.
halfvec(precisión media, 16 bits) y cuantización, que reducen a la mitad la memoria del índice con una pérdida de recall normalmente asumible.pgvectorscalecon índice DiskANN, que mueve parte del índice a disco y estira el techo de memoria cuando escalas más allá de la RAM cómoda.
Con HNSW + halfvec + cuantización, pgvector maneja del orden de 10 millones de embeddings de 1536 dimensiones en una única instancia media (tipo db.r6g.xlarge) con p95 por debajo de ~60 ms. Para la inmensa mayoría de productos, eso es más que suficiente.
La tabla que resume la decisión
| Opción | Punto dulce | Fortaleza | El coste que asumes |
|---|---|---|---|
| pgvector | Hasta ~10M vectores | Cero infra nueva, consistencia transaccional, todo en tu SQL | Filtrado por metadatos como post-filtro; sin sharding nativo |
| pgvectorscale (DiskANN) | ~10-50M vectores | Estira el techo de memoria sin salir de Postgres | Extensión adicional que operar |
| Qdrant / Weaviate | 10-50M+ con filtrado exigente | Filtrado dentro del grafo, búsqueda híbrida (denso + léxico) | Un sistema más que desplegar, sincronizar y monitorizar |
| Pinecone Serverless | Escala grande, equipo pequeño | Cero operación, precio por consulta predecible | Vendor lock-in y coste por query a volumen |
Cuándo pgvector es la respuesta correcta
Quédate en Postgres si, como la mayoría, cumples varias de estas:
- Estás por debajo de ~10-20M de vectores y no ves un crecimiento de un orden de magnitud a corto plazo.
- Tus vectores viven junto a datos relacionales que ya consultas (usuarios, documentos, permisos, tenancy). Poder hacer un
JOINentre tus embeddings y tus tablas de negocio, dentro de una misma transacción, vale más de lo que parece. - Quieres una sola cosa que operar, respaldar y auditar. Dos sistemas de almacenamiento significan dos pipelines de sincronización, dos superficies de fallo y dos facturas.
- Trabajas con datos sensibles (salud, financiero) donde mantener los embeddings en la misma base con RGPD, residencia y control de acceso ya resueltos elimina toda una categoría de problemas de cumplimiento.
Este último punto es decisivo en los verticales donde más trabajamos: en FinTech o HealthTech, "un sistema más al que se le envían datos de cliente" no es una nota al pie, es una conversación con legal y con seguridad.
Cuándo NO: las señales para migrar
Un motor dedicado sí compensa. La clave es migrar por una razón medida, no por la portada de un benchmark. Estas son las señales reales:
- Filtrado por metadatos muy selectivo a escala. Es el talón de Aquiles honesto de
pgvector: el filtrado por metadatos ocurre como post-filtro sobre el conjunto de candidatos, no dentro del grafo HNSW. En una colección de 5M con un filtro del 10% de selectividad, acabas escaneando cientos de miles de candidatos. Qdrant resuelve eso dentro del recorrido del grafo y es materialmente más rápido en consultas selectivas. Si tu producto filtra portenant,idiomaocategoríaen cada query, esto te va a doler antes que el volumen. - Cruzas la franja de 10-50M de vectores. El techo práctico de vectores residentes en Postgres en 2026 está en las decenas de millones bajas. Por encima, un motor dedicado suele ganar en latencia y coste. Antes de saltar, prueba
pgvectorscale(DiskANN) o el sharding con Citus. - Necesitas búsqueda híbrida de primera clase (denso + BM25/léxico con re-ranking) como funcionalidad central del producto, no como añadido.
- Escritura concurrente muy alta. El índice HNSW de
pgvectorpuede degradarse bajo carga intensa de escrituras; si reindexas en tiempo real a gran ritmo, notarás la presión. - Escalado horizontal.
pgvectorno tiene sharding nativo. Particionar a mano o con FDW rompe la localidad ANN y fragiliza las consultas filtradas.
Regla operativa concreta: cuando un índice de ~10M ocupa unos 8 GB de RAM y la p95 se instala por encima de ~250 ms pese a haber ajustado ef_search, es el momento de mirar alternativas. No antes.
El camino en GCP
Si tu backend vive en Cloud Run o GKE —como en buena parte de los proyectos en Go que construimos—, tienes el recorrido resuelto sin salir del ecosistema:
- Cloud SQL para PostgreSQL con
pgvector: el default. Tus embeddings viven al lado de tus datos, con backups, réplicas y IAM que ya conoces. - AlloyDB cuando el volumen aprieta: su índice vectorial (ScaNN) empuja el techo bastante más arriba manteniendo la compatibilidad con Postgres, así que estiras la arquitectura antes de tener que introducir un sistema nuevo.
- Solo cuando esas dos opciones se quedan cortas de verdad tiene sentido añadir un Qdrant gestionado o Pinecone al diagrama.
La ventaja de este orden no es solo técnica: cada sistema nuevo que metes en producción es coste de operación, de sincronización y de gente que tiene que entenderlo a las 3 de la madrugada cuando algo falla.
La recomendación de Dribba
Empieza con pgvector. Casi siempre. Es aburrido, y "aburrido" en infraestructura es un cumplido: una pieza menos que puede romperse, una factura menos, un pipeline de sincronización menos.
Diseña, eso sí, con la puerta de salida abierta: mantén tu capa de acceso a datos detrás de una interfaz limpia (el mismo principio que aplicamos con un LLM gateway para evitar el vendor lock-in), de forma que cambiar el motor de vectores el día que los números lo pidan sea un reemplazo acotado y no una reescritura. Y toma esa decisión con datos tuyos —recall, p95, coste por consulta a tu volumen real—, no con el benchmark de otro sobre una carga que no se parece a la tuya.
Migrar por adelantado a una base de datos vectorial dedicada "por si acaso" es, casi siempre, resolver un problema que no tienes a cambio de otros que sí vas a tener.
Si estás decidiendo la arquitectura de datos de una funcionalidad de IA —o quieres una segunda opinión sénior sobre si tu stack de RAG aguantará el próximo orden de magnitud—, en Dribba llevamos desde 2011 construyendo backend en Go sobre GCP y sistemas de IA en producción. Cuéntanos tu caso.
Para profundizar: cómo integrar RAG y LLMs en apps empresariales, el marco de decisión Cloud Run vs GKE para tu backend en Go y cómo controlar el coste de tokens de LLM con FinOps.
