pgvector: búsqueda semántica sin salir de Postgres

Actualizado: 2026-05-03

La búsqueda semántica — recuperar documentos por significado y no por coincidencia de palabras — se ha convertido en el cimiento silencioso de buena parte del boom de aplicaciones LLM. Detrás de cada sistema RAG, de cada asistente que consulta documentación interna, de cada buscador “inteligente”, hay la misma mecánica: un modelo convierte texto en un vector de cientos o miles de dimensiones, y la aplicación busca vectores cercanos a la consulta. Lo interesante es que para montar esa mecánica no hace falta, en la mayoría de casos, introducir una base de datos nueva en el stack. pgvector^[1] convierte un PostgreSQL ya existente en una base vectorial perfectamente competente.

Puntos clave

• pgvector extiende PostgreSQL con un tipo de dato vector y operadores de distancia coseno, euclídea y producto interior.
• El índice IVFFlat divide los vectores en clusters (k-means) y busca solo en los clusters más cercanos a la consulta — búsqueda aproximada (ANN) a cambio de velocidad.
• La regla de oro para lists: ≈ sqrt(N) en la carga inicial. En tiempo de consulta, ivfflat.probes entre 10 y 20 da 95-98% de recall.
• Ventaja decisiva: los filtros relacionales (WHERE category = 'tech') y el ranking vectorial coexisten en la misma query SQL — sin coordinar dos stores.
• Por encima de 10-20 millones de vectores con QPS sostenido alto, las bases vectoriales dedicadas (Qdrant, Pinecone) rinden mejor.

Por qué la búsqueda semántica necesita un tipo de índice distinto

Un embedding moderno — pensemos en los 1536 valores que produce text-embedding-ada-002 de OpenAI — vive en un espacio de alta dimensionalidad. Encontrar el vector más parecido a otro es, matemáticamente, calcular una distancia (coseno, euclídea o producto interior) contra cada vector almacenado. Con diez mil documentos, un escaneo secuencial tarda milisegundos. Con diez millones, tarda segundos, y el usuario ya se ha marchado.

Los índices B-tree clásicos de Postgres, pensados para ordenar escalares, no sirven para vectores. Un B-tree necesita un orden total; en un espacio de 1536 dimensiones ese orden simplemente no existe. La solución práctica de la industria ha sido renunciar a la exactitud y aceptar búsqueda aproximada — ANN, approximate nearest neighbor — aceptando perder un pequeño porcentaje de recall a cambio de órdenes de magnitud de velocidad.

pgvector implementa esta idea con índices IVFFlat: la tabla se particiona en k clusters durante la construcción del índice (una especie de k-means), y cada búsqueda compara la consulta únicamente contra los vectores de los clusters más cercanos. El parámetro probes, ajustable por consulta, controla cuántos clusters se inspeccionan: más probes significa mejor recall y más latencia; menos probes, lo contrario.

Cuándo pgvector es la decisión correcta

La pregunta honesta no es “¿es pgvector lo mejor?” sino “¿qué gana mi proyecto usando Qdrant, Pinecone o Milvus en lugar de extender el Postgres que ya tiene?”. La respuesta suele ser: menos de lo que parece.

Ya tienes backups, monitorización, replicación y una política de acceso funcionando sobre Postgres. Añadir un servicio vectorial separado duplica esa superficie: otro proceso que parchear, otro backup que probar, otra ventana de mantenimiento que coordinar.

Hay además una ventaja arquitectónica que se infravalora sistemáticamente. En una base vectorial dedicada, los metadatos (autor, categoría, fecha, permisos) viven en otra parte del sistema. Cualquier filtro complejo requiere coordinar dos stores. Con pgvector, WHERE category = 'tech' AND user_id = 42 y el ranking vectorial viven en la misma query y el planificador de Postgres decide cómo ejecutarlos juntos. Ese único hecho elimina una capa entera de código pegamento.

Dicho esto, pgvector no es la respuesta universal. Por encima de 10-20 millones de vectores con QPS sostenido alto, las bases dedicadas rinden mejor sin tanto tuneo. Por encima de 2000 dimensiones empiezan a aparecer problemas de memoria. Pero para el 80% de proyectos LLM — chatbots internos, asistentes de documentación, buscadores de soporte — esos límites quedan muy lejos.

Del CREATE EXTENSION a un índice que rinde

Empezar es casi trivial:

CREATE EXTENSION vector;

CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    category TEXT,
    embedding vector(1536)
);

CREATE INDEX documents_embedding_idx ON documents
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 1000);

SET ivfflat.probes = 10;

SELECT id, content, 1 - (embedding <=> $1::vector) AS score
FROM documents
WHERE category = 'tech'
ORDER BY embedding <=> $1::vector
LIMIT 5;

Los tres operadores de distancia: – <=> para distancia coseno (similitud semántica, el más usado). – <-> para distancia euclídea. – <#> para producto interior negativo.

La similitud legible se obtiene como 1 - (a <=> b) para tener un rango de 0 a 1.

Tres detalles operativos que marcan la diferencia

1. Construir el índice con CREATE INDEX CONCURRENTLY para no bloquear la tabla durante la operación — relevante en cualquier tabla con escrituras en producción.
2. Reindexar periódicamente si el patrón de inserción es intenso: IVFFlat particiona en construcción, y si la distribución de vectores nuevos cambia respecto a la original, el recall se degrada con el tiempo. Un REINDEX mensual o trimestral basta.
3. Combinar filtros relacionales con el orden vectorial en la misma query: Postgres aplica primero el filtro (usando sus índices normales) y rankea vectorialmente solo el subconjunto resultante, lo que suele ser drásticamente más rápido que rankear todo y filtrar después.

La regla de oro para lists: ≈ sqrt(N) durante la carga inicial (para un millón de vectores, ~1000 clusters). En tiempo de consulta, ivfflat.probes entre 10 y 20 suele dar 95-98% de recall con latencias de decenas de milisegundos.

Señales de que has superado pgvector

Hay síntomas claros de que el proyecto ha crecido más allá de lo que la extensión cubre cómodamente:

• Latencia p95 sostenida por encima de 100 ms con los parámetros bien ajustados.
• Índices que ya no caben en RAM y obligan a leer de disco en cada consulta.
• Necesidad de técnicas de compresión vectorial para reducir la huella de memoria.

En ese punto, migrar a Qdrant suele ser la opción pragmática: mantiene la propiedad de poder autoalojarlo y escala mucho mejor. Pero llegar hasta ahí es una señal de éxito, no un fracaso arquitectónico: significa que el proyecto funciona lo bastante bien como para tensar la infraestructura.

Si usas LangChain o Chroma para el pipeline RAG, la migración de retriever desde pgvector a Qdrant es un cambio de pocas líneas — siempre que hayas respetado la abstracción del retriever desde el principio.

Conclusión

pgvector no es el eslabón más rápido del mercado ni pretende serlo. Es la pieza que permite añadir búsqueda semántica a un producto existente sin multiplicar la superficie operativa, reutilizando el Postgres que tu equipo ya sabe operar, backupear y auditar. Con RAG convertido en patrón por defecto, esa combinación de pragmatismo e ingeniería conservadora es lo que separa los prototipos que llegan a producción de los que se quedan en demo.

1. pgvector