pg_vectorsearch: PRISM, más rápido que HNSW en Postgres

100 millones de vectores en 6 milisegundos y con cuatro veces menos RAM que un índice HNSW: eso es lo que promete PRISM, el índice de pg_vectorsearch, la nueva extensión open source para búsqueda vectorial en PostgreSQL que publica Tiger Data. Si tu producto ya usa pgvector para búsqueda semántica o recomendaciones y estás viendo latencias o costos de memoria que no escalan, esta es una alternativa que vale la pena medir en tu propio dataset.

¿Qué es pg_vectorsearch y por qué compite con pgvector?

pg_vectorsearch es una extensión de PostgreSQL para búsqueda de vecinos más cercanos aproximados (ANN, por sus siglas en inglés) e incluye PRISM, un nuevo método de acceso al índice. Su diferencial es que no te obliga a migrar nada: si ya tienes columnas vector o halfvec de pgvector, puedes construir un índice PRISM encima tal como están.

La tabla no se reescribe ni se copia, y tus consultas siguen funcionando con los mismos operadores (<->, <#>, <=>). La extensión está escrita en C y se publica bajo la licencia de PostgreSQL. El repositorio, alojado en la organización timescale/pg_vectorsearch, acumula 77 estrellas y 5 forks: es un proyecto joven, y eso se nota en su estado.

¿El estado exacto? Alpha. El propio README advierte que está pensada para pruebas y no para producción, y que actualizar entre versiones preliminares puede no ser posible: hay que estar dispuesto a eliminar y recrear la extensión y sus índices. Ese detalle cambia por completo la decisión de adoptarla hoy.

¿Cómo funciona el índice PRISM por dentro?

PRISM significa Partitioned Routing Index for Similarity Matching y conceptualmente se parece al IVFFlat de pgvector, pero apoyado en técnicas recientes de cuantización y ruteo. El mecanismo tiene cuatro piezas:

• Árbol jerárquico de centroides: las consultas recorren este árbol para encontrar los clusters más cercanos, y el buffer cache de PostgreSQL lo mantiene caliente en memoria.
• Cuantización RaBitQ: los vectores se codifican y se guardan en posting lists con un layout de página optimizado para cálculo de distancia con SIMD (AVX2, AVX512 y NEON).
• Filtrado en dos etapas: la codificación RaBitQ lleva cotas de error teóricas, así que la búsqueda puede descartar vectores que no pueden ser vecinos cercanos y reordenar solo un subconjunto contra los vectores de precisión completa.
• Reranking desde el heap: el resultado final se valida contra el vector full-precision almacenado en la tabla.

Un punto que suele romper este tipo de índices es la escritura. Aquí, cada INSERT agrega el vector a la posting list que le corresponde, así que las listas crecen y no se parten solas. Para eso existe prism_rebalance, un procedimiento que divide las listas sobredimensionadas en el lugar, además del clásico REINDEX.

Las bases teóricas están citadas de forma explícita en el repositorio: RaBitQ y su cuantización binaria con cotas de error (SIGMOD 2024), SPFresh con el protocolo LIRE para actualizaciones incrementales (SOSP 2023), SPANN (NeurIPS 2021) y el whitepaper de ScaNN for AlloyDB para clustering jerárquico.

¿Cuánto más rápido es frente a HNSW e IVFFlat?

Según el anuncio publicado en el blog de Tiger Data, el índice PRISM sirve 100 millones de vectores en 6 milisegundos con cuatro veces menos RAM que HNSW, y con construcciones de índice en menos de dos horas. Esa es la afirmación central y conviene leerla con cuidado: viene del equipo que desarrolla la extensión, no de un benchmark independiente.

El README añade que, comparado con el índice basado en grafos HNSW, PRISM es más rápido a igual recall sobre un dataset de 100 millones de vectores y en una instancia con un cuarto de la memoria. También afirma ser más veloz que IVFFlat y HNSW tanto en consultas como en construcción de índices.

Ojo con la letra chica: recall equivalente es la parte clave de la frase. Un índice vectorial puede ser rapidísimo si devuelve resultados peores, y aquí la comparación se hace con la misma calidad de recuperación. En el mismo repositorio aparece como proyecto relacionado pgvectorscale, el índice vectorial basado en DiskANN que sigue la misma línea de trabajo para quien necesita otra arquitectura.

¿Por qué esto importa justo ahora?

El mercado de bases de datos vectoriales pasó de ser un nicho a una línea de presupuesto. Según MarketsandMarkets, ese mercado vale US$2.652,1 millones en 2025 y llegará a US$8.945,7 millones en 2030, con una tasa de crecimiento anual compuesta del 27,5% en el período. La consultora señala además que América del Norte concentraba el 36,6% del mercado en 2025 y que el segmento de servicios crecerá al 32,7% anual.

Traducido a tu operación: la demanda de búsqueda vectorial crece más rápido que la paciencia de los equipos de infraestructura. En la mayoría de los stacks de IA, la memoria RAM es el rubro que define el tamaño de la instancia y, por lo tanto, la factura. Una técnica que mantiene el recall con una fracción de la memoria ataca directamente el costo por consulta.

¿Qué significa esto para tu startup?

Antes de tocar nada, tres movimientos concretos:

1. Mide tu propio dataset antes de creerle al anuncio. Corre un benchmark con tus embeddings reales y compara PRISM contra el índice HNSW que ya tengas: latencia p95, recall a k fijo y memoria del nodo. Los números de un desarrollador sobre un dataset ajeno son un techo optimista, no una promesa.
2. No migres producción mientras esté en alpha. Prueba en una réplica o en una tabla espejo. La advertencia de que una actualización puede exigir recrear la extensión y los índices es una ventana de caída que no quieres descubrir un viernes.
3. Si PostgreSQL ya es tu base, el costo de evaluarlo es bajo. Puedes construir el índice PRISM junto al HNSW que ya tienes, verificar con EXPLAIN que el planner lo elija y recién entonces eliminar el índice viejo. Nada de tu tabla ni de tus consultas cambia.

La ruta más simple para empezar es la de tipos nativos: guardar los vectores en columnas vec32 (float32) o vec16 (float16) de la propia extensión, lo que además puede reducir a la mitad el espacio que ocupan los vectores en la tabla. Si ya tienes vector o halfvec de pgvector, usas la ruta de compatibilidad y eliges el operator class según tu métrica de distancia:

• L2 (<->): vec32_l2_ops o vec16_l2_ops
• Producto interno (<#>): vec32_ip_ops o vec16_ip_ops
• Coseno (<=>): vec32_cosine_ops o vec16_cosine_ops

Al reemplazar un índice HNSW, el mapeo es directo: vector_<métrica>_ops pasa a vec32_<métrica>_ops, y halfvec_<métrica>_ops a vec16_<métrica>_ops. El parámetro que casi todos los despliegues van a tocar es prism.nprobe: en 0 funciona en automático, con un recall de alrededor de 0.95 según la documentación; súbelo para ganar recall y bájalo para ganar velocidad.

Requisitos técnicos para probarlo: PostgreSQL 18+ con headers de desarrollo, un compilador de C11 (GCC 11+ o Clang 14+), Meson como sistema de build y, opcionalmente, CBLAS para acelerar la codificación RaBitQ.

Lo que todavía no está resuelto

Una adopción seria exige leer también las limitaciones. La extensión es alpha, el proyecto tiene pocas estrellas y forks todavía, y el manejo de listas sobredimensionadas depende de ejecutar prism_rebalance de forma explícita: no hay particionado automático de las posting lists. Sumado al requisito de PostgreSQL 18+, el universo de equipos que pueden probarlo hoy es acotado.

Dicho eso, la dirección es clara. Durante años, la conversación de búsqueda vectorial en Postgres giró alrededor de un solo proyecto y de sus dos índices. Que aparezca una alternativa open source que ataca el costo de memoria, y que lo haga aceptando las tablas existentes sin migración, es exactamente el tipo de competencia que abarata infraestructura para toda la industria.

Conclusión

pg_vectorsearch llega con una propuesta atractiva y un estado que pide cautela: PRISM promete reducir la memoria necesaria para servir cientos de millones de vectores, y su compatibilidad con pgvector elimina la fricción de adopción. Pero es alpha, requiere PostgreSQL 18+ y las cifras de rendimiento vienen del propio desarrollador.

El movimiento sensato es de bajo riesgo: agrega el índice sobre una copia de tus datos, mide con tus propios embeddings y decide con números. Si tu factura de RAM por búsqueda vectorial te está apretando, ya tienes una hipótesis que vale la pena testear esta semana.

Fuentes

• pg_vectorsearch (repositorio oficial) (fuente original)
• Tiger Data Blog
• Vector Database Market, MarketsandMarkets