Tiger Data has released pg_vectorsearch, an open source PostgreSQL extension for vector similarity search, currently in alpha. Its PRISM index uses data partitioning and compression instead of the graph-based approach used by pgvector’s HNSW index, reducing memory requirements and index build times.
According to the authors, pg_vectorsearch enables faster, more memory-efficient vector search directly in PostgreSQL, reducing the infrastructure required to handle large vector datasets. The extension supports existing pgvector columns, allowing applications to perform vector search without a separate database. To use the new capabilities, developers must install the extension and create a PRISM index on the vector column:
CREATE EXTENSION pg_vectorsearch; CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);
In Tiger Data’s own benchmarks using 100 million vectors, PRISM built an index in 1 hour and 40 minutes on a machine with 128 GB of memory, while HNSW (Hierarchical Navigable Small World) took 42 hours on a machine with 512 GB of memory. Formerly known as Timescale, Tiger Data is the company behind TimescaleDB, the open source PostgreSQL extension for time-series data and real-time analytics.
Erik Nordström, senior staff engineer at Tiger Data, Matvey Arye, principal engineer at Tiger Data, and Noah Hein, staff product marketing manager at Tiger Data, write:
PRISM brings a partition-based approach to PostgreSQL, similar to the approach used by newer dedicated vector search systems. Instead of connecting every vector to its neighbors in a graph, PRISM groups similar vectors into partitions and stores them as a list in a compressed format that is densely packed into database pages.
While HNSW is an approximate nearest-neighbor algorithm that quickly finds vectors similar to a query in large datasets, PRISM narrows searches to relevant partitions and scans compressed vectors sequentially. This reduces index size and avoids costly random memory or disk access, enabling faster vector search with less RAM directly in PostgreSQL.
Michael Freedman, cofounder and CTO of Tiger Data, published an article describing the architecture of the PRISM vector index. The index in pg_vectorsearch combines hierarchical clustering to narrow the search space, compressed vectors for efficient sequential scanning, and RaBitQ quantization to reduce expensive distance calculations. It duplicates vectors near partition boundaries to improve recall and relies on PostgreSQL’s native storage, logging, and concurrency mechanisms.
Source: Freedman on LinkedIn
Incremental rebalancing is not yet fully implemented, so frequent data changes may require rebuilding the index to maintain search efficiency. Freedman explains:
The harder problem is maintaining the clustering as the dataset changes. Centroids don't automatically move when new vectors arrive, and posting lists gradually lose their original physical locality. We currently support limited on-demand splitting of oversized posting lists for flat indexes, but the more general rebalancing operations, including merging and reassignment, are not implemented yet.
In a popular Hacker News thread, the overall reaction is one of technical interest but caution. Practitioners see potential in faster vector search with lower memory requirements inside PostgreSQL, but raise questions about independent benchmark validation, whether pg_vectorsearch could replace pgvectorscale, and the lack of support for filtered searches. Hermon Hagos comments:
Vector search just got cheaper (...) For those of us building RAG apps on one database and a tight budget, that matters. Fast semantic search without spinning up a separate vector store or a bigger server is real money saved. It is still alpha, so do not ship it to clients yet, but this is one to watch closely.
Although not independently validated, Tiger Data’s benchmarks use an open source tool, measure recall@10 against exact search results, and compare both indexes under the same PostgreSQL configuration and instance types, using pgvector’s 16-bit halfvec for HNSW.
The new vector extension requires PostgreSQL 18 or later and currently supports vectors with up to 1968 dimensions. Filtered vector searches combining WHERE and ORDER BY are not supported until general availability. The project's code is available on GitHub. Tiger Data plans to move its existing pgvectorscale extension into maintenance mode.
