Tiger Data launches pg_vectorsearch, open source extension that cuts vector search memory in PostgreSQL

Tiger Data, a company previously known as Timescale and the creator of TimescaleDB, launched pg_vectorsearch on November 7, 2026, an open source vector search extension for PostgreSQL. The new release, still in alpha stage, comes with an index called PRISM, designed as an alternative to the HNSW used by pgvector, the most popular extension in the ecosystem for this type of search. According to the announcement covered by InfoQ, the goal is clear: reduce the infrastructure needed to handle large volumes of vectors directly inside the database.

For those building semantic search or RAG (Retrieval-Augmented Generation) applications in Brazil, this carries real weight. Running a heavy vector index usually means spinning up a larger instance, sometimes billed in dollars, just to keep the index in memory. An extension that promises the same result with less RAM attacks that cost directly.

How the PRISM index works

pgvector solves similarity search with HNSW (Hierarchical Navigable Small World), a graph algorithm that connects each vector to its nearest neighbors. It is fast, but the entire graph needs to remain accessible with low latency, which puts pressure on memory.

PRISM replaces the graph with partitioning and compression. Instead of building a network of connections, it groups similar vectors into partitions and stores each one as a compressed list, packed into the database's own pages. Tiger Data's engineers describe the difference this way:

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.

Erik Nordström, Matvey Arye, and Noah Hein, engineers and product marketing at Tiger Data

In practice, a search does not traverse the entire graph: it identifies the relevant partitions and sequentially scans the compressed vectors within them, avoiding expensive random access to memory or disk. Michael Freedman, co-founder and CTO of Tiger Data, detailed the architecture in an article published on LinkedIn: the index combines hierarchical clustering to reduce the search space, compressed vectors for efficient sequential scanning, and RaBitQ quantization to cut the cost of distance calculations. To avoid losing recall at partition boundaries, PRISM duplicates vectors near the limits between groups, and all of this runs on top of PostgreSQL's own native storage, logging, and concurrency mechanisms.

How to install and use it

The extension works on top of existing pgvector columns, so it does not require migrating data to a separate vector database. To enable the index, just two commands are needed:

CREATE EXTENSION pg_vectorsearch;
CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);

The minimum requirement is PostgreSQL 18, and PRISM currently supports vectors with up to 1,968 dimensions, which covers most embedding models in use today. One relevant limitation before considering production use: filtered searches combining WHERE and ORDER BY do not work yet and will only arrive in the general availability release.

The benchmark numbers

Tiger Data published its own tests with 100 million vectors. PRISM built the index in 1 hour and 40 minutes, on a machine with 128 GB of memory. HNSW, on the same volume of data, took 42 hours running on a machine with 512 GB. The benchmarks have not been independently validated, but Tiger Data used an open source tool to measure recall@10 against exact search results, comparing the two indexes under the same PostgreSQL configuration and the same instance type, with HNSW using pgvector's 16-bit halfvec.

The nearly 25-fold difference in build time, with a quarter of the memory, is the number that stands out most, but it is worth remembering that it comes from a test controlled by the product's own maker.

What still needs to mature

The weakest point today is keeping the index updated as data changes. Incremental rebalancing is not fully implemented, which means that, in write-heavy workloads, it may be necessary to rebuild the index to maintain search efficiency. Freedman explains the challenge:

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.

Michael Freedman, co-founder and CTO of Tiger Data

Added to this is the lack of filtered search (WHERE combined with ORDER BY), a feature common in real applications that combine metadata with semantic similarity, such as filtering by product category before ranking by embedding.

How the community received the news

A popular discussion on Hacker News mixes technical interest with caution. Comments question the independent validation of the benchmarks, whether pg_vectorsearch will replace pgvectorscale (another extension from Tiger Data itself), and the lack of support for filtered searches. Hermon Hagos summed up the moderate enthusiasm:

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.

Hermon Hagos, comment on Hacker News

Tiger Data has already signaled the next step within its own product family: pgvectorscale, the extension the company had maintained until now as its main performance answer to plain pgvector, will move into maintenance mode, giving way to pg_vectorsearch as its main bet.

What changes for developers in Brazil

For Brazilian teams that currently run RAG or semantic search on top of pgvector, pg_vectorsearch is not yet an option for production: it is alpha, without full rebalancing and without filtered search, a feature that practically every real RAG application uses sooner or later. But the code is open on the project's GitHub, and it is already possible to run it in a test environment with PostgreSQL 18, using existing pgvector columns without needing to migrate the schema.

The reasonable path for anyone who wants to evaluate it: install the extension on a development database, create the PRISM index alongside the existing HNSW, and compare recall and query time with your own dataset, before betting on any third-party benchmark. If Tiger Data's numbers hold up outside the lab, the infrastructure bill for vector search inside PostgreSQL, without spinning up a dedicated vector store like Pinecone or Qdrant, becomes much cheaper to sustain.