Timescale unveils pg_vectorsearch, an index extension that claims to outperform pgvector

Timescale's pg_vectorsearch introduces the PRISM index: compatible with existing pgvector tables and, according to the project, faster than IVFFlat and HNSW both in query and index build time.

Anyone running similarity search on PostgreSQL today is likely using pgvector, with its IVFFlat or HNSW indexes. Timescale, the company behind the TimescaleDB time-series extension, published pg_vectorsearch on GitHub, a new extension that claims to be faster than both in queries and also in index construction. The project is open source, under the PostgreSQL license.

The central point is the PRISM index (Partitioned Routing Index for Similarity Matching). According to the project's documentation, it is "conceptually similar to pgvector's IVFFlat", but built with more recent quantization, routing, and partitioning techniques, implemented in C.

How PRISM organizes the search

PRISM uses a hierarchical tree of centroids to partition vectors into clusters, kept warm in memory via Postgres's own buffer cache. Vectors are quantized with RaBitQ and stored in posting lists with a page layout optimized for distance computation via SIMD (AVX2, AVX512, NEON).

The sequence of a query, as described in the README, follows four steps:

1. Walks the centroid tree to find the nearest clusters (via buffer cache)
2. Scans the posting lists for candidates (buffer cache, asynchronous I/O)
3. Applies RaBitQ's two-stage filtering: estimate, error bound, rerank
4. Performs full-precision reranking from the table and returns the k nearest neighbors

The speed gain comes mainly from step 3: RaBitQ encoding carries theoretical error bounds (described in the RaBitQ paper, from SIGMOD 2024) that make it possible to mathematically safely discard vectors that cannot be nearest neighbors. As a result, fewer candidates need the expensive rerank against the full-precision vectors.

The practical advantage: no need to swap tables

For those who already have a database running with pgvector, the most relevant point isn't the internal architecture, but compatibility. pg_vectorsearch can be installed alongside pgvector and build a PRISM index directly on existing vector or halfvec columns, without rewriting or copying the table.

The README provides the full migration example:

-- The table you already have, with pgvector's HNSW index
CREATE EXTENSION vector;

CREATE TABLE documents (
 id bigserial PRIMARY KEY,
 body text,
 embedding vector(384)
);
CREATE INDEX documents_embedding_hnsw
 ON documents USING hnsw (embedding vector_l2_ops);

-- Installs pg_vectorsearch and builds the index on the existing column
CREATE INDEX documents_embedding_prism
 ON documents USING prism (embedding vec32_l2_ops);

After validating the gain with EXPLAIN (COSTS OFF), just drop the old index with DROP INDEX documents_embedding_hnsw. Queries keep using the same operators (<->, <#>, <=>), so no query in the code needs to change.

For those starting from scratch, the extension also offers native types, vec32 (float32) and vec16 (float16, which cuts the space vectors occupy in the table in half), without depending on pgvector:

CREATE EXTENSION pg_vectorsearch;

CREATE TABLE items (
 id serial PRIMARY KEY,
 embedding vec32(3) STORAGE PLAIN
);

CREATE INDEX ON items USING prism (embedding vec32_l2_ops);

-- 0 = automatic (~0.95 recall). Increase for more recall, decrease for more speed.
SET prism.nprobe = 40;

The numbers the project presents

According to Timescale, compared to HNSW (a graph-based index, today considered the recall benchmark in pgvector), PRISM is faster at the same recall level on a dataset of 100 million vectors, running on an instance with a quarter of the memory HNSW would require. There is no detailed latency or throughput table by configuration in the published material; the claim stays in the README text, with no direct link to a full benchmark report.

For those evaluating the switch, this matters: the memory figure is the most concrete part of the comparison, because HNSW is known to be RAM-hungry precisely because it keeps the entire graph accessible. Cutting that footprint to a quarter, if confirmed in production, changes the infrastructure cost math for anyone running vector search at scale, not just query latency.

Why it's not yet time to migrate to production

The project itself classifies its status as alpha, with the explicit warning: "intended for testing, not production". Updates between pre-releases may not be compatible with each other, and the current recommendation, in case of an upgrade, is to drop and recreate the extension and its indexes.

There are also environment requirements that weigh on the decision to test now or wait:

• PostgreSQL 18 or higher, with development headers
• GNU C11 compiler (GCC 11+ or Clang 14+)
• Meson build system
• CBLAS as an optional dependency, to speed up RaBitQ encoding

Anyone on PostgreSQL 15, 16, or 17 in production, a common scenario in Brazil, simply cannot test it without first migrating the database to version 18. This pushes the evaluation of pg_vectorsearch to later (or in parallel with) the Postgres upgrade itself, which naturally delays the kind of load test that would validate the memory and latency numbers cited in the README.

What remains open

Ongoing maintenance is also a point worth watching: since posting lists only grow with insertions and never split on their own, the extension depends on a routine called prism_rebalance to rebalance lists that have grown too large, outside the automatic flow of a REINDEX. The project's own maintenance guide acknowledges current limitations in this mechanism, without detailing what they are.

Also left open is a public, reproducible benchmark with a clear methodology (dataset, hardware, recall parameters) to back up the comparison with IVFFlat and HNSW outside the README text. Timescale already maintains another vector search extension for Postgres, pgvectorscale, based on DiskANN, which positions pg_vectorsearch as the company's third bet in the same area, not its first. For those administering databases with embeddings in production, the reasonable path for now is to follow the project's changelog and set aside a test environment, not swap the index on the live database.