# Tiger Data releases pg_vectorsearch, a PRISM-based vector index for PostgreSQL

published: 2026-11-07T10:05:45.799Z
topic: infrastructure
source: https://www.infoq.com/news/2026/11/postgresql-vector-search/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=AI%2C+ML+%26+Data+Engineering
url: https://aiagentnews.io/stories/tiger-data-releases-pg-vectorsearch-a-prism-based-vector-index-for-postgresql

Tiger Data has released pg_vectorsearch, an open source PostgreSQL extension for vector similarity search that is currently in alpha. Its PRISM index uses partitions and compressed storage instead of a graph, and the company reports much faster index builds than HNSW on a large benchmark.

Tiger Data, formerly Timescale, has published pg_vectorsearch, an open source PostgreSQL extension for vector similarity search. The project is in alpha. Rather than linking vectors in a graph as pgvector's HNSW index does, the PRISM index groups similar vectors into partitions and stores them in a compressed, densely packed format, which the company says lowers memory use and index build time. Existing pgvector columns are supported, so applications can run vector search without a separate database.

To try it, developers install the extension and create a PRISM index on a vector column using the prism access method with the vec32_l2_ops operator class. In Tiger Data's own benchmarks on 100 million vectors, PRISM built its index in 1 hour and 40 minutes on a machine with 128 GB of memory, while HNSW took 42 hours on a machine with 512 GB. The benchmarks have not been independently validated.

The extension requires PostgreSQL 18 or later and supports vectors with up to 1968 dimensions. Filtered searches that combine WHERE and ORDER BY are not supported until general availability. Incremental rebalancing is also incomplete, so frequent data changes may require rebuilding the index. Tiger Data plans to move its pgvectorscale extension into maintenance mode.

## Why it matters if you build agents

Teams running RAG or agent memory on PostgreSQL may be able to avoid a separate vector store for large datasets, but they should test the index on their own data first. Because the project is alpha and lacks filtered searches and full rebalancing, it fits evaluation better than production. Anyone relying on pgvectorscale should plan for its move to maintenance mode.