Pinecone lanza Pg_pinecone, una extensión de búsqueda de código abierto para Postgres

Pinecone lanzó el 27 de octubre de 2026 pg_pinecone, una extensión de código abierto para Postgres con licencia Apache 2.0 que incorpora a las columnas pgvector que las aplicaciones ya almacenan el motor de búsqueda vectorial que, según la empresa, utiliza a gran escala. En las pruebas de rendimiento comunicadas por la empresa, el índice nativo de la extensión para 1 millón de vectores de 768 dimensiones ocupó 136 MB, frente a 2,0 GB para HNSW con halfvec y 4,1 GB para vectores de tamaño completo.

El lanzamiento se presentó en una publicación de anuncio redactada por Harshita Daddala y Anthony Mahanna. Según la publicación, la forma habitual de ejecutar búsquedas vectoriales en Postgres consiste en utilizar un índice de grafo como HNSW, que requiere cada vez más memoria para mantener el rendimiento, tarda mucho en crearse y reduce la precisión de las búsquedas con filtros; cuando una consulta se limita a un usuario o inquilino, un índice de grafo puede devolver menos filas que las especificadas en el LIMIT de la consulta. En cambio, pg_pinecone aplica el filtro durante la búsqueda, lo que, según Pinecone, permite que incluso una búsqueda con un ámbito reducido devuelva un conjunto completo de resultados; además, con su motor predeterminado, los datos nunca salen de Postgres.

Tres motores para un mismo índice

pg_pinecone funciona con columnas vectoriales que ya están almacenadas en pgvector. La aplicación se conecta a Postgres de la misma manera y envía el mismo SQL, por ejemplo ORDER BY embedding <=> $1 LIMIT 10, mientras que las tablas, incluidos los vectores completos, permanecen donde están y Postgres sigue siendo el sistema de registro.

Cada tabla utiliza uno de tres motores. El motor nativo, que es el predeterminado, crea y consulta su índice íntegramente en Postgres, sin necesidad de una cuenta de Pinecone, una clave de API ni llamadas de red. El motor pgvector consulta un índice pgvector existente, HNSW o IVFFlat; el repositorio de GitHub del proyecto indica que es adecuado para tablas que ya tienen un índice pgvector y no aplican filtros. El motor remoto envía las búsquedas a un índice sin servidor del servicio administrado de Pinecone y está pensado para tablas que han superado la capacidad de un único servidor Postgres. Para cambiar el motor de una tabla basta con una llamada a pinecone.set_engine(); las consultas no cambian y todos los cambios de motor son reversibles.

Cómo busca el motor nativo

Al igual que HNSW de pgvector, el motor nativo utiliza un algoritmo aproximado de vecinos más cercanos, pero sustituye el grafo por un índice de archivo invertido que agrupa los vectores similares en clústeres. Cada vector se almacena como un código RaBitQ cuantizado, de aproximadamente un bit por dimensión más algunos valores de corrección, mediante un método que la publicación atribuye a Gao y Long, SIGMOD 2024. Los códigos de cada clúster se agrupan, de modo que una búsqueda lee unas pocas páginas contiguas en lugar de recorrer un grafo saltando de un punto a otro.

La búsqueda se ejecuta en tres pasos: primero, sondea los clústeres más cercanos comparando el vector de consulta con el centroide de cada clúster; después, calcula una distancia estimada para cada fila a partir de su código RaBitQ y conserva los mejores candidatos; por último, vuelve a ordenar esos candidatos utilizando los vectores completos de la tabla.

El filtrado se realiza durante la búsqueda. Pinecone señaló que HNSW de pgvector aplica los filtros después de la búsqueda: primero encuentra los vecinos más cercanos y luego aplica la cláusula WHERE. Por ello, un filtro muy restrictivo descarta la mayoría de los candidatos y los escaneos iterativos vuelven a completar la lista, lo que consume tiempo y, cuando se utiliza relaxed_order, reduce la precisión. El motor nativo almacena junto al código de cada fila el valor de la columna de filtrado y, al crear el índice, cuenta las filas correspondientes a cada valor. Para los filtros restrictivos, que de forma predeterminada abarcan el 3 % de las filas o menos, aplica el filtro antes de la búsqueda: recorre todas las filas coincidentes de todos los clústeres y calcula la puntuación de cada una usando su vector completo, de modo que los resultados son exactos. Para los filtros más amplios, utiliza un filtrado en una sola etapa: busca en hasta la mitad de los clústeres más cercanos y comprueba el filtro dentro de cada clúster antes de calcular las puntuaciones.

Las nuevas inserciones se incorporan al clúster más cercano y se pueden consultar de inmediato. Como los centroides permanecen en la posición que se les asignó al crear el índice, la publicación recomienda ejecutar REINDEX o activar el mantenimiento automático después de cambios importantes, como una carga masiva que duplique el tamaño de la tabla, para reequilibrar los clústeres.

Resultados de las pruebas comunicados por Pinecone

Pinecone comparó el motor nativo con el índice HNSW de pgvector, utilizando vectores de tamaño completo y halfvec, en 1 millón de vectores wiki_dpr de 768 dimensiones. Las pruebas se ejecutaron en una instancia AWS r6id.4xlarge con 16 vCPU y 128 GB de RAM: la latencia sin filtros, el tiempo de creación y el tamaño del índice se midieron en una sesión con PostgreSQL 17; la búsqueda con filtros, en otra sesión con PostgreSQL 18; y una configuración con memoria limitada, en una tercera sesión. La latencia se comunica como la mediana p50 con k=10 y un cliente. La empresa indicó que la configuración completa y los comandos para repetir las pruebas están disponibles en un README del arnés de pruebas de rendimiento del repositorio.

Para 1 millón de vectores, Pinecone comunicó que el índice nativo ocupaba 136 MB, frente a 2,0 GB para HNSW con halfvec y 4,1 GB para vectores de tamaño completo. En las búsquedas sin filtros, la empresa informó de una latencia de 1,3 ms con una exhaustividad de 0,95, frente a 1,7 ms para HNSW con halfvec y 2,7 ms para los vectores de tamaño completo; con una exhaustividad de 0,99, la latencia fue de 2,3 ms, frente a 4,7 ms y 6,7 ms, respectivamente. Con un filtro que coincidía con el 10 % de las filas, Pinecone informó de que el motor nativo alcanzó una exhaustividad de 1,000 en 12,3 ms con el filtrado en una sola etapa, mientras que HNSW, con escaneos iterativos, alcanzó una exhaustividad máxima de 0,920 en 5,9 ms; con un filtro del 1 %, comunicó una exhaustividad de 0,981 en 8,3 ms. El tiempo de creación del índice fue, según la empresa, de 45 segundos para el motor nativo, frente a 62 segundos para HNSW con halfvec y 79 segundos para los vectores de tamaño completo.

Disponibilidad y funciones opcionales de Pinecone

pg_pinecone requiere PostgreSQL 17 o 18, acceso de superusuario y que pgvector esté instalado en el servidor. Se instala a partir de versiones precompiladas disponibles en GitHub o como la imagen pineconeteam/pg_pinecone en Docker Hub, que el archivo README describe como la imagen pgvector/pgvector con pg_pinecone añadido y publicada con una etiqueta por cada versión principal de Postgres, como 0.11.0-pg17; para ejecutar el motor remoto también hay que cargar la extensión mediante shared_preload_libraries. La configuración crea las extensiones vector y pg_pinecone, y genera un índice mediante una llamada a pinecone.create_index(); además, el proyecto puede compilarse desde el código fuente con una cadena de herramientas de Rust y cargo-pgrx 0.19.2.

Con una clave de API opcional de Pinecone, el motor remoto sincroniza las incrustaciones con un índice de Pinecone en segundo plano, mientras las búsquedas siguen ejecutándose en Postgres hasta que termina la copia. La publicación describe otras tres funciones opcionales: embed() llama al servicio de inferencia de Pinecone para convertir texto en incrustaciones desde SQL, funciona tanto con el motor nativo como con el remoto y está cubierta por el nivel gratuito de Pinecone para una primera compilación; la búsqueda de texto completo BM25 se ejecuta junto con la búsqueda vectorial en la misma tabla, y permite realizar consultas BM25, vectoriales o híbridas desde SQL; y rerank() reordena los resultados principales mediante los modelos de reclasificación de Pinecone.

La documentación de docs.pinecone.io abarca la instalación, los motores de almacenamiento, el cambio de motor y la búsqueda de texto completo, mientras que el repositorio incluye una referencia de SQL, una guía operativa y una guía de recuperación ante desastres. Pinecone describió esta como la primera versión del proyecto, afirmó que mantiene pg_pinecone y revisa cada solicitud de cambios, y señaló que elaborará la hoja de ruta pública a partir de los comentarios compartidos mediante las incidencias de GitHub, su comunidad de Discord y las sesiones mensuales de consulta.