El 13 de octubre de 2026, Tiger Data (antes Timescale) publicó los resultados de su nueva extensión pg_vectorsearch, que promete revolucionar la búsqueda vectorial en PostgreSQL. En una máquina de 64 vCPU y 512 GiB de RAM, pgvector tardó 42 horas en construir un índice HNSW sobre 100 millones de vectores, mientras que pg_vectorsearch logró la misma tarea en solo 49 minutos y respondió consultas en la mitad del tiempo. Esta noticia es relevante para México y Latinoamérica porque cada vez más empresas de la región adoptan PostgreSQL para aplicaciones de inteligencia artificial, y la eficiencia en la construcción de índices impacta directamente en costos y tiempos de desarrollo.

¿Qué es pg_vectorsearch y cómo funciona?

pg_vectorsearch es una extensión para PostgreSQL que introduce un nuevo método de acceso a índices llamado PRISM (Partitioned Routing Index for Similarity Matching). Según su documentación, es conceptualmente similar al IVFFlat de pgvector, pero con un enfoque de particionamiento que reduce drásticamente el uso de memoria. Mientras que HNSW mantiene un grafo grande en memoria para ser rápido, PRISM solo conserva un árbol pequeño y escanea listas de publicaciones compactas para el resto.

Además, la extensión es compatible con los tipos de datos de pgvector: vec32 y vec16 son binariamente compatibles con vector y halfvec, por lo que puedes crear un índice PRISM en una tabla existente sin migrar datos.

Los números detrás del anuncio

Los datos publicados por Tiger Data muestran una diferencia abismal en la construcción de índices:

• pgvector HNSW: 42 horas para 100 millones de vectores en una máquina de 512 GiB.
• pg_vectorsearch PRISM: 49 minutos en la misma máquina, con consultas a la mitad del tiempo.

Sin embargo, el análisis detallado revela que la comparación no es del todo justa. El benchmark de Tiger Data utilizó una configuración de HNSW con m=16 y ef_construction=200, mientras que el valor por defecto de pgvector es 64. Esta configuración más exigente mejora la calidad del grafo pero incrementa considerablemente el tiempo de construcción. Además, no se especifica el parámetro maintenance_work_mem, crucial para el rendimiento de HNSW. Cuando el grafo no cabe en esa memoria, PostgreSQL emite una advertencia y la construcción se ralentiza significativamente.

En máquinas con menos RAM, como una de 128 GiB, HNSW ni siquiera terminó de construirse, mientras que PRISM logró consultas de 6 ms con 95% de recall usando cuatro veces menos memoria. Esto sugiere que PRISM es especialmente beneficioso en entornos con recursos limitados.

Implicaciones para la búsqueda vectorial en producción

La noticia ha generado debate en la comunidad. En Hacker News, usuarios como esafak cuestionaron la falta de métricas como QPS (consultas por segundo) y p99, así como pruebas de concurrencia. Tiger Data respondió que parte de esas pruebas están en el roadmap para la versión GA. También se señala que la búsqueda filtrada, un punto débil de pgvector, aún es básica en PRISM: el ejecutor aplica la cláusula WHERE después de que el índice emite los top-k, lo que puede devolver muy pocas filas si los filtros no están correlacionados con la distancia vectorial.

Otro aspecto importante es que pgvectorscale, la extensión anterior de Tiger Data basada en DiskANN, entrará en modo mantenimiento. El CTO de la compañía, mfreed, explicó que partes del grafo podían volverse inalcanzables y degradar el recall, por lo que decidieron empezar de nuevo con un índice de particiones. Esto muestra cómo una tecnología puede pasar de ser el estándar a quedar obsoleta en poco tiempo.

Recomendaciones para desarrolladores

Si actualmente usas pgvector y sufres con los tiempos de construcción de índices HNSW, antes de migrar a pg_vectorsearch considera estas optimizaciones:

• Usa halfvec para reducir a la mitad el tamaño del índice.
• Mantén ef_construction en 64 a menos que necesites mayor recall.
• Activa hnsw.iterative_scan (disponible desde pgvector 0.8.0) para consultas filtradas que devuelven pocas filas.

Si decides probar pg_vectorsearch, hazlo en un entorno de staging o réplica, ya que aún está en fase alpha. La versión GA promete búsqueda filtrada en streaming y rebalanceo incremental automático.

El futuro de la búsqueda vectorial en PostgreSQL

A pesar de las críticas, la dirección es prometedora. Otra extensión, VectorChord, también utiliza clustering con vectores cuantizados y afirma duplicar el QPS de pgvector en sus propios benchmarks. Aunque son números de proveedores, el hecho de que dos equipos independientes apuesten por índices de particiones sugiere que HNSW podría no ser la solución definitiva para todos los casos.

Para los desarrolladores de México y Latinoamérica, esta noticia es una invitación a evaluar alternativas y a no quedarse con la primera opción. La eficiencia en la construcción de índices puede marcar la diferencia entre un proyecto de IA viable y uno que consume recursos excesivos.

¿Qué usas actualmente para búsqueda vectorial? ¿Has probado pg_vectorsearch? Comparte tu experiencia en los comentarios.