pgvector

pgvector es una extensión de código abierto para PostgreSQL que añade búsqueda de similitud vectorial a cualquier base de datos Postgres existente. Creada por Andrew Kane en 2021 y publicada bajo la Licencia PostgreSQL (una licencia de código abierto permisiva similar a MIT), permite almacenar embeddings de alta dimensionalidad como un tipo de columna nativa y ejecutar consultas aproximadas de vecinos más cercanos utilizando operadores SQL estándar. La extensión está disponible en github.com/pgvector/pgvector, cuenta con más de 13,000 estrellas en GitHub a partir de abril de 2026 y es compatible de forma nativa con Amazon RDS, Amazon Aurora, Google Cloud SQL, Azure Database for PostgreSQL, Supabase y Neon, entre otros. No hay proveedores, suscripciones ni tarifas por consulta: el costo es simplemente lo que pagas por ejecutar Postgres.

La extensión añade tres operadores de distancia: <-> para la distancia L2 (euclidiana), <#> para el producto interno y <=> para la distancia coseno. Soporta dos tipos de índices: IVFFlat (búsqueda aproximada basada en particiones que requiere un paso de entrenamiento) y HNSW (Hierarchical Navigable Small World, añadido en la versión v0.5.0 en octubre de 2023, que se construye de forma incremental y ofrece una mayor recuperación sin fase de entrenamiento). Puedes almacenar vectores de hasta varios miles de dimensiones dependiendo de la versión, lo que la hace compatible con modelos de embeddings de OpenAI, Cohere, Google y otros. Las consultas se ejecutan dentro de Postgres, por lo que puedes hacer JOIN de los resultados vectoriales con tus tablas relacionales habituales, aplicar políticas de seguridad a nivel de fila y usar tu pool de conexiones y ORM existentes sin ninguna infraestructura nueva.

Lo que pgvector realmente hace en abril de 2026

La versión estable actual de pgvector (v0.8.x) se distribuye como una extensión estándar de Postgres: un solo comando CREATE EXTENSION vector; la habilita en cualquier base de datos compatible. Defines una columna vectorial con un recuento de dimensiones declarado (embedding vector(1536) para embeddings de OpenAI ada-002, por ejemplo), insertas los embeddings junto a tus datos habituales con un INSERT estándar y consultas usando operadores de distancia en una cláusula WHERE u ORDER BY. El índice HNSW, añadido en octubre de 2023, es ahora el tipo de índice recomendado para cargas de trabajo en producción de más de aproximadamente 100,000 vectores. Soporta inserciones concurrentes sin un paso de reconstrucción y ofrece consistentemente una recuperación superior al 95 por ciento a velocidades de consulta razonables. IVFFlat sigue disponible para cargas de trabajo donde el costo de la fase de entrenamiento es aceptable y la memoria es limitada. Ambos tipos de índices soportan la creación paralela de índices en versiones más recientes de Postgres. La extensión se mantiene activamente, con commits regulares y los principales proveedores de la nube adoptando las nuevas versiones a las pocas semanas de su publicación.

Dónde se sitúa pgvector frente a Pinecone y Qdrant

El mercado de bases de datos vectoriales en abril de 2026 se divide a grandes rasgos en tres grupos: servicios gestionados creados específicamente (Pinecone), bases de datos dedicadas de código abierto (Qdrant, Weaviate, Chroma) y extensiones de Postgres (pgvector). Las ventajas y desventajas son concretas y arquitectónicas.

pgvector vs. Pinecone: Pinecone es un servicio de código cerrado y exclusivamente gestionado, construido desde cero para la búsqueda aproximada de vecinos más cercanos a gran escala. Su arquitectura distribuida maneja miles de millones de vectores con mayor fluidez de lo que pgvector puede hacer dentro de una única instancia de Postgres. Ofrece actualizaciones de índices en tiempo real, filtrado de metadatos integrado directamente en el índice (no como una cláusula WHERE de SQL posterior a la consulta) y una interfaz REST/SDK sin SQL. La versión serverless de Pinecone comienza siendo nominalmente gratuita, pero los niveles de pago empiezan alrededor de $70 al mes una vez que los tamaños de los índices crecen. La principal diferencia radica en el límite de rendimiento y la dependencia del proveedor frente a la simplicidad de mantenerse dentro de Postgres. Si ya tienes una aplicación en Postgres, Pinecone requiere un nuevo servicio, un nuevo cliente de API, una nueva relación de facturación y código de aplicación que consulte dos almacenes de datos diferentes y correlacione los resultados. pgvector mantiene todo en un solo lugar.

pgvector vs. Qdrant: Qdrant es una base de datos vectorial de código abierto y autoalojable escrita en Rust, también disponible como un servicio en la nube gestionado. Utiliza HNSW como su índice principal (el mismo algoritmo que pgvector adoptó en la versión v0.5.0) pero implementado específicamente para cargas de trabajo vectoriales, lo que se traduce en un mayor QPS bruto con una recuperación equivalente, particularmente bajo una fuerte carga concurrente. Qdrant trata el filtrado de payloads como una primitiva de indexación de primera clase: los filtros de metadatos están integrados en el recorrido HNSW, no se aplican como un filtro posterior a la consulta. Los benchmarks muestran consistentemente que Qdrant supera a pgvector en rendimiento con alta concurrencia. El costo es operativo: Qdrant es un servicio con estado separado con su propio despliegue, formato de almacenamiento, API y monitorización. No puedes hacer JOIN de los resultados de Qdrant con tu tabla de usuarios de Postgres en una sola consulta; debes obtener los datos de Qdrant y luego correlacionarlos en el código de la aplicación o con un segundo viaje a la base de datos. Para los equipos con la capacidad DevOps para gestionar otro servicio y cargas de trabajo vectoriales que superarán los 20-50 millones de filas, Qdrant es la opción técnica más sólida. Para todos los demás, el argumento de pgvector de "es solo tu Postgres" es difícil de ignorar.

"Migramos de Pinecone a pgvector el trimestre pasado. Nuestra latencia de consulta p99 es mayor, pero eliminamos toda una dependencia de infraestructura y nuestra factura mensual se redujo en unos $400. Para nuestra escala, menos de 5M de vectores, ha sido la decisión correcta." -- throwaway_ml_eng, Hacker News, noviembre de 2023

Cómo es la realidad del flujo de trabajo diario

El flujo de trabajo más común de pgvector es un pipeline RAG (generación aumentada por recuperación): fragmentar documentos, generar embeddings a través de una llamada a la API de OpenAI o Cohere, almacenar el embedding y el texto de origen en una tabla de Postgres, y luego, en el momento de la consulta, generar un embedding para la pregunta del usuario y recuperar los top-K fragmentos más cercanos para inyectarlos en un prompt de LLM. Con pgvector, esto es una sola consulta SQL. El embedding vive en la misma base de datos que tus usuarios, documentos, permisos y registros de auditoría. La seguridad a nivel de fila se aplica automáticamente. Tu monitorización existente de Postgres (pg_stat_statements, registros de consultas lentas, Datadog, etc.) cubre las consultas vectoriales. Las migraciones son simplemente sentencias ALTER TABLE.

El lanzamiento de la versión v0.5.0 en octubre de 2023, que añadió la indexación HNSW, fue el momento en que la comunidad consideró ampliamente que pgvector estaba listo para producción. Antes de ese lanzamiento, IVFFlat era la única opción de índice aproximado. IVFFlat requiere un paso de entrenamiento explícito (SET ivfflat.probes) después de cargar tus datos, degrada la recuperación con recuentos de sondeo bajos en grandes conjuntos de datos y no puede actualizarse de forma incremental sin un reentrenamiento periódico. Múltiples interrupciones en producción y publicaciones de blogs de 2022-2023 se remontaron a la degradación de la recuperación de IVFFlat a medida que crecían las colecciones. HNSW eliminó el requisito de entrenamiento y elevó el estándar de la recuperación práctica. El hilo de incidencias de GitHub que anunciaba la versión v0.5.0 acumuló cientos de comentarios en cuestión de días, con equipos informando de un alivio inmediato de problemas de producción de larga data.

"El soporte del índice HNSW en la versión 0.5.0 fue lo que hizo que pgvector fuera realmente utilizable para nosotros. Antes de eso, nos encontrábamos con escaneos completos de tablas en cualquier cosa de más de un millón de filas. Después de HNSW, es como el día y la noche." -- datasci_pete, hilo de incidencias de GitHub, pgvector/pgvector, finales de 2023

Para quién está diseñado pgvector

pgvector es ideal para equipos que ya operan Postgres y desean búsqueda vectorial sin añadir un nuevo servicio a su stack. Esto cubre una gran parte del mercado de startups y scale-ups: cualquiera en Supabase, Neon, RDS, Cloud SQL o una instancia de Postgres autogestionada puede habilitar pgvector con un solo comando y comenzar a almacenar embeddings el mismo día. Se adapta a pipelines RAG, funciones de búsqueda semántica, motores de recomendación y flujos de trabajo de detección de duplicados a escalas de hasta aproximadamente 10-20 millones de vectores con un rendimiento de consulta aceptable. Es particularmente adecuado para aplicaciones SaaS multi-inquilino donde las políticas de seguridad a nivel de fila de Postgres proporcionan aislamiento de datos por cliente sin ninguna capa de control de acceso personalizada en la capa vectorial. Los equipos con capacidad DevOps limitada que no pueden justificar la gestión de otro servicio con estado encontrarán atractiva la simplicidad operativa de pgvector, incluso cuando las cifras de rendimiento no sean las mejores de su clase.

Lo que pgvector no es

pgvector no es un reemplazo para las bases de datos vectoriales creadas específicamente a gran escala o bajo fuertes cargas de escritura concurrentes. A partir de 50 millones de vectores, o en aplicaciones donde el almacén de vectores se consulta miles de veces por segundo, la sobrecarga del planificador de consultas de Postgres de pgvector y la concurrencia basada en MVCC se convierten en limitaciones medibles. Los equipos en esta situación informan consistentemente que migran a Qdrant (autoalojado) o Pinecone (gestionado) en lugar de intentar ajustar los límites de pgvector.

pgvector no incluye búsqueda híbrida nativa. Para los pipelines RAG que necesitan clasificación de palabras clave BM25 combinada con similitud vectorial (un patrón cada vez más estándar en los sistemas de recuperación en producción a partir de 2025-2026), debes ensamblar las piezas tú mismo utilizando la búsqueda de texto completo de Postgres, pg_trgm o un índice BM25 externo, y luego fusionar las puntuaciones en el código de la aplicación. Sistemas dedicados como Weaviate y Elasticsearch ofrecen búsqueda híbrida como un modo de primera clase con parámetros alfa ajustables. Si la recuperación híbrida es fundamental para tu producto, pgvector requiere un esfuerzo de ingeniería adicional significativo para igualar lo que los sistemas dedicados proporcionan de forma predeterminada.

pgvector tampoco te ayuda si tu aplicación no está en Postgres. Si tu almacén de datos principal es MongoDB, MySQL, Cassandra o un almacén de objetos puro, pgvector no es para ti: necesitas una base de datos vectorial dedicada o un servicio gestionado.