pgvector en detalle
pgvector es una extensión de Postgres que enseña a la base de datos un nuevo tipo de dato y una nueva forma de clasificar filas: por distancia geométrica en lugar de igualdad o rango.
Busca en todas las páginas de la documentación
pgvector es una extensión de Postgres que enseña a la base de datos un nuevo tipo de dato y una nueva forma de clasificar filas: por distancia geométrica en lugar de igualdad o rango.
Esta página se mantiene conceptual y no repite la sintaxis de tipos, el DDL de índices o los patrones de esquemas que ya se cubren en las otras páginas de esta sección.
vector y operadores, indexación IVFFlat y HNSW, diseño de esquemas de almacenamiento RAG, escalado de pgvector.Un embedding es una lista de números producida por un modelo de aprendizaje automático, y esa lista está pensada para ser leída como las coordenadas de un punto en un espacio de alta dimensionalidad.
Dos fragmentos de texto, imágenes o clips de audio que significan cosas similares se entrenan para aterrizar cerca unos de otros en ese espacio, mientras que el contenido no relacionado aterriza lejos.
pgvector almacena cada embedding como un valor vector, y trata ese valor de la misma manera que Postgres trata un entero o una marca de tiempo: una columna tipada con operadores definidos.
La idea central detrás de la búsqueda vectorial es que "significado similar" se convierte en "distancia pequeña", lo que convierte una pregunta semántica en una pregunta de geometría que SQL puede responder con ORDER BY y LIMIT.
La distancia en sí no es una idea fija, ya que existen varias formas matemáticamente válidas de medir cuán separados están dos puntos.
La distancia Euclidiana (L2) mide la distancia en línea recta a través del espacio, de la misma manera que una regla mediría la distancia entre dos puntos en un papel.
La distancia del coseno ignora la longitud de cada vector y mide solo el ángulo entre ellos, lo que importa cuando los embeddings de un modelo varían en magnitud pero no en dirección.
El producto interior mide una mezcla de ángulo y magnitud a la vez, y es el ajuste natural para modelos entrenados explícitamente para maximizar una puntuación de producto escalar.
Ninguna de estas métricas es universalmente "correcta", ya que la elección adecuada depende de cómo se entrenó y normalizó el modelo de embedding.
Una analogía simple ayuda aquí: imagina cada documento como una ciudad en un mapa, donde las ciudades que discuten temas similares se agrupan en barrios.
Encontrar "los documentos más relevantes" se convierte en "las ciudades más cercanas", y el mapa en sí lo define el modelo de embedding, no pgvector.
pgvector no crea ese mapa, solo le da a Postgres las herramientas para medirlo y buscarlo eficientemente.
A pequeña escala, la búsqueda de similitud es un problema de geometría de fuerza bruta: calcula la distancia del vector de consulta a cada vector almacenado, luego ordena y toma los mejores resultados.
Ese enfoque es exacto, pero su coste crece linealmente con el número de filas, por lo que deja de ser rápido una vez que una tabla alcanza decenas de miles de vectores.
La indexación de vecino más cercano aproximado (ANN) existe para romper esa relación lineal organizando los vectores de antemano para que una consulta solo tenga que mirar un subconjunto pequeño y prometedor.
La compensación que se está haciendo es explícita: un índice ANN renuncia a la garantía de encontrar los vecinos más cercanos exactos a cambio de encontrar vecinos que probablemente estén lo suficientemente cerca, a una fracción del coste.
Esto es fundamentalmente diferente de un índice B-tree, que nunca sacrifica la corrección por la velocidad.
Recall (recuperación) es el término para cuántas veces un índice ANN realmente devuelve los verdaderos vecinos más cercanos en comparación con un escaneo exacto de fuerza bruta, y es un dial ajustable en lugar de una garantía fija.
Girar ese dial hacia un mayor recall generalmente cuesta más latencia de consulta y más tiempo de construcción, y girarlo hacia un menor recall recupera velocidad.
Lo que hace que pgvector sea interesante arquitectónicamente es que no añade la búsqueda ANN a Postgres como un servicio separado.
Registra el tipo vector y sus operadores de distancia a través del mismo sistema de clases de operadores en el que todos los métodos de índice de Postgres ya se basan para saber cómo comparar valores.
Debido a eso, un índice ANN sobre vectores es un índice de primera clase de Postgres, no una estructura externa que la base de datos simplemente tolera.
El planificador de consultas trata un escaneo de índice vectorial de la misma manera que trata un escaneo B-tree o GiST al estimar el coste y decidir si usar el índice o no.
-- Las clases de operadores son cómo Postgres sabe que un operador de distancia puede impulsar un escaneo de índice
SELECT opcname, amname
FROM pg_opclass oc
JOIN pg_am am ON am.oid = oc.opcmethod
WHERE opcname LIKE 'vector%';Es por eso que cambiar el operador de distancia de la consulta sin que coincida con la clase de operador del índice derrota silenciosamente el índice: el planificador ya no puede probar que el orden del índice coincide con el orden solicitado por la consulta.
Los espacios de alta dimensionalidad se comportan de manera contraintuitiva, y esto se manifiesta como la "maldición de la dimensionalidad", donde los puntos tienden a volverse aproximadamente equidistantes entre sí a medida que aumenta el número de dimensiones.
Ese efecto es una de las razones por las que los índices ANN aceptan la aproximación: en dimensiones muy altas, encontrar el vecino más cercano matemáticamente exacto a menudo no es significativamente mejor que encontrar uno muy cercano.
Combinar la búsqueda vectorial con filtros tradicionales, como "documentos similares propiedad de este inquilino", es más difícil de lo que parece, ya que un índice ANN está optimizado para el ordenamiento por distancia, no para la selectividad arbitraria de predicados.
Filtrar antes o después del escaneo ANN puede cambiar el recall de maneras que son fáciles de pasar por alto durante las pruebas en conjuntos de datos pequeños.
La búsqueda híbrida, que combina la relevancia de palabras clave y vectorial, existe precisamente porque la similitud vectorial pura a veces devuelve resultados que están geométricamente cerca pero pragmáticamente incorrectos.
La deriva de embeddings es un riesgo de producción que no tiene nada que ver con la mecánica de pgvector y todo que ver con el modelo que generó los vectores y que cambia con el tiempo.
Si el modelo de embedding se actualiza, los vectores antiguos y nuevos ya no tienen garantizado vivir en un espacio comparable, y mezclarlos corrompe silenciosamente los rankings de distancia.
La observabilidad para una función de búsqueda vectorial debe rastrear el recall contra un conjunto de consultas etiquetado a lo largo del tiempo, no solo la latencia de consulta, porque la latencia por sí sola no puede revelar un índice que se degrada silenciosamente.
Las representaciones cuantificadas, como los vectores de media precisión, son parte de cómo el ecosistema gestiona el coste de almacenamiento y memoria de los índices ANN a medida que crecen los corpus.
La lección arquitectónica más amplia es que pgvector tiene éxito extendiendo los puntos de extensibilidad existentes de Postgres en lugar de reinventarlos, que es también por lo que hereda las garantías transaccionales de Postgres de forma gratuita.
| Estrategia de Búsqueda | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Escaneo exacto de fuerza bruta | Siempre correcto, cero mantenimiento de índice | El coste escala linealmente con el número de filas | Tablas pequeñas o análisis puntuales |
| Índice de vecino más cercano aproximado (ANN) | Coste de consulta sub-lineal a escala | El recall es probabilístico, no garantizado | Búsqueda semántica en producción a escala significativa |
| Híbrido palabra clave + vectorial | Captura coincidencias de términos exactos que ANN puede pasar por alto | Más partes móviles para ajustar y monitorizar | Búsqueda orientada al usuario donde la precisión en nombres o códigos importa |
Permite a Postgres clasificar filas por cercanía geométrica entre vectores de embedding, que es la operación de la que dependen la búsqueda semántica, la recuperación RAG y las recomendaciones.
Solo en la medida en que el modelo de embedding codificó ese significado como geometría, por lo que la distancia es un proxy de la similitud, no una garantía de ella.
El coste de comparación de fuerza bruta crece linealmente con el número de filas, por lo que se vuelve demasiado lento una vez que una tabla contiene más de aproximadamente decenas de miles de vectores.
Significa que se permite que el índice falle ocasionalmente en encontrar las filas más cercanas verdaderas a cambio de responder mucho más rápido que un escaneo exacto.
Registra sus operadores de distancia a través del mismo sistema de clases de operadores que utilizan todos los métodos de acceso a índices de Postgres, por lo que el planificador de consultas puede razonar sobre los escaneos de índices vectoriales exactamente como los escaneos B-tree o GiST.
Sí, estima el coste de la misma manera que lo hace para cualquier otro tipo de índice y elige entre un escaneo secuencial y un escaneo de índice en consecuencia.
El recall mide cuántas veces un índice ANN devuelve los verdaderos vecinos más cercanos en comparación con un escaneo exacto, y un índice rápido que silenciosamente devuelve coincidencias pobres es peor que uno ligeramente más lento que no lo hace.
Las diferentes versiones del modelo generalmente producen vectores en espacios incomparables, por lo que mezclar embeddings antiguos y nuevos puede corromper silenciosamente los rankings de distancia.
Los índices ANN están construidos para optimizar el ordenamiento por distancia, no la selectividad arbitraria de predicados, por lo que el filtrado interactúa con el recall de maneras que son fáciles de pasar por alto.
El recall contra un conjunto de consultas fijo y etiquetado debe rastrearse a lo largo del tiempo, ya que la latencia por sí sola no puede revelar un índice cuya calidad de resultados se está degradando silenciosamente.
vector, los operadores de distancia y los límites de dimensiones que esta página asume.Versiones de Stack: Esta página fue escrita para pgvector 0.8+. Por lo demás, es conceptual y no está ligada a una versión menor específica de PostgreSQL.
Revisado por Chris St. John·Última actualización: 15 jul 2026