Las bases de datos vectoriales integradas en PostgreSQL mediante la extensión pgvector se han popularizado para alimentar búsquedas semánticas y sistemas de Retrieval-Augmented Generation (RAG) sobre millones de embeddings. Sin embargo, cuando una tabla de vectores supera cierto tamaño, las consultas de vecinos más cercanos (k-NN) basadas en el operador <=> comienzan a degradarse y la latencia deja de ser aceptable para aplicaciones en producción. Esta guía explica por qué pgvector se ralentiza al escalar, qué métricas internas lo delatan y qué decisiones técnicas permiten recuperar el rendimiento sin abandonar PostgreSQL.
El cuello de botella habitual es la búsqueda exacta por fuerza bruta sobre la distancia coseno, euclídea o producto interior, que compara el vector de consulta contra todas las filas de la tabla: con índices ANN como HNSW o IVFFlat se reduce el coste a un subconjunto, pero solo si los parámetros están bien ajustados y el conjunto de entrenamiento es representativo. Conviene revisar el plan de ejecución con EXPLAIN ANALYZE, controlar el ratio entre list_rows y la longitud promedio de las listas en IVFFlat, y dimensionar ef_construction, ef_search y m en HNSW según la cardinalidad real. Cuando estas palancas se agotan, las recomendaciones incluyen añadir restricciones de partición, prefiltrar metadatos con índices B-tree, habilitar quantization, paralelizar lecturas y, en último término, recurrir a extensiones especializadas o motores nativos como pgvecto.rs, Lantern o bases vectoriales dedicadas (Qdrant, Milvus, Weaviate).
La guía va dirigida a ingenieros de datos y desarrolladores que mantienen cargas RAG, motores de recomendación o búsqueda semántica sobre PostgreSQL, y repasa también las limitaciones de memoria del maintenance_work_mem, los efectos de la réplica de streaming y las trade-offs entre precisión del recall y latencia.