pg_vectorsearch vs pgvector HNSW: Read the Benchmark Right

The interesting number in the pg_vectorsearch announcement is not a latency figure. It is that HNSW did not finish building on a 128 GiB machine at all. If your vector table has outgrown RAM, that is the problem this extension is aimed at, and the rest of the benchmark should be read in that light.

This piece walks through what shipped, what the published numbers actually show, what they leave out, and how to trial PRISM next to an existing pgvector setup without touching your production index.

What Tiger Data shipped

Tiger Data announced pg_vectorsearch on 13 October 2026. It is a native PostgreSQL index access method called PRISM, released under the PostgreSQL License, with the code on GitHub. The repository labels it alpha: intended for testing, not production.

PRISM is an IVF-style index. k-means splits the vector space into clusters; a small centroid tree, kept warm in the buffer cache, routes each query to the nearest clusters; the index then scans those clusters sequentially. Each vector is stored as a RaBitQ code of roughly one bit per dimension, and RaBitQ's error bounds prune most candidates before the final rerank against full-precision vectors.

The compatibility story is the part most teams will care about. The extension ships its own vec32 and vec16 types, which the README describes as binary-compatible with pgvector's vector and halfvec. Both extensions can be installed side by side, and you can build a PRISM index directly on an existing pgvector column without rewriting the table. Operators (<->, <#>, <=>) follow pgvector's conventions.

The numbers, as published

The headline test used 100 million Cohere embeddings on AWS r8i instances. Recall is recall@10 against brute-force results, and the HNSW runs used pgvector's 16-bit halfvec, which the authors say gave HNSW its best speed-to-size trade-off.

Read that table column by column. On the same 512 GiB box, PRISM's p50 at 95% recall is 4 ms against HNSW's 8 ms: better, but not a different league. The gap that matters is build time (49 minutes versus 42 hours) and index size (25 GB versus 180 GB). PRISM on a machine with a quarter of the memory still served 95% recall at 6 ms.

The 1M-vector test tells the same story at small scale. HNSW on a 4 GiB c8g.large took about 21.7 hours to build a 2.05 GB index because, per the authors, the graph did not fit in memory during construction. PRISM built a 280 MB index in about three minutes and answered at 3 ms (95% recall) versus HNSW's 122 ms on the same instance.

What the benchmark doesn't tell you

This is a vendor benchmark of a vendor's own index, and it is honest about some of its gaps. Before you quote it in a design doc, note what is missing:

• No throughput figures. Only p50 latency is published. There are no QPS numbers and no multi-client concurrency results; the roadmap lists multi-client throughput testing as GA hardening work.
• No vector dimensions stated for the benchmark datasets, and the 1M dataset is not named.
• No IVFFlat comparison in the published results, even though PRISM is conceptually closest to IVFFlat.
• No filtered search. Streaming search with WHERE filters is a planned GA feature, so the common "nearest documents for this tenant" query is not what was measured.
• A fresh, static index. Inserts work, but the authors warn that heavy churn causes recall drift until you rebalance.

The useful part: the benchmark tool, rekall, is public. If you plan to switch, rerun it on your own embeddings and your own instance size rather than trusting anyone's chart, including this one. The same discipline applies to any tool comparison, which is why our guide to comparing developer tools starts with your workload, not the vendor's.

Why partitions beat graphs on memory

HNSW stores, for every vector, edges to its neighbours. Search hops between nodes with random reads that CPUs struggle to prefetch, so it performs well only while most of the graph sits in RAM. Once it spills to disk, every hop becomes a scattered read. The post sums it up bluntly: "HNSW is memory hungry."

PRISM trades that for sequential scans of compact clusters. A ~1-bit-per-dimension code is far smaller than a graph with edge lists, and scanning contiguous pages suits SIMD (the extension has AVX2, AVX-512 and NEON code paths). Vectors near cluster boundaries are stored in more than one partition, a technique the authors compare to ScaNN's SOAR, trading a little storage for recall. They also point to Google's ScaNN, Microsoft's SPANN and turbopuffer as using the same broad approach.

The authors concede the flip side: graphs still suit small, fast-changing datasets, because HNSW adds one vector at a time while partitions need enough data to form meaningful clusters. If your table is a few hundred thousand rows that change constantly, HNSW is still the sensible default.

The alpha caveats that matter

• PostgreSQL 18 or later only. Managed Postgres fleets on 15–17 can't try it without an upgrade.
• Build after you load. Index sizing is based on the row count at CREATE INDEX time; creating it on an empty table and filling it later is not recommended.
• No automatic re-partitioning. Posting lists grow on insert; you split them with prism_rebalance or REINDEX.
• Deletes don't free space until REINDEX.
• No upgrade path between prereleases. Plan to drop and recreate the extension and its indexes.
• Use STORAGE PLAIN on vector columns; the README says the default external storage adds a fetch during reranking that the planner doesn't account for.

How to trial it next to pgvector

Because PRISM reads existing pgvector columns, the low-risk trial is to add an index beside your HNSW one on a staging copy and let the planner choose. This is the README's own migration path:

CREATE EXTENSION pg_vectorsearch;

CREATE INDEX documents_embedding_prism
    ON documents USING prism (embedding vec32_l2_ops);

-- 0 = auto (targets about 95% recall); raise for more recall
SET prism.nprobe = 40;

EXPLAIN SELECT id FROM documents
ORDER BY embedding <-> $1 LIMIT 10;

-- only once EXPLAIN shows the prism index being used:
-- DROP INDEX documents_embedding_hnsw;

Match the operator class to your distance: vec32_cosine_ops or vec32_ip_ops for cosine and inner product, and the vec16_* classes for halfvec columns. If you keep migration SQL in a repo, run it through the SQL formatter so reviewers can diff it cleanly, and capture recall and latency for both indexes from the same query set before you drop anything.

What happens to pgvectorscale

Tiger Data's earlier extension, pgvectorscale, used a DiskANN-inspired graph index. The post says that on some datasets, especially low-dimensional ones, parts of the graph could become unreachable and recall degraded, and heuristic fixes didn't generalise. pgvectorscale, which the authors describe as stable and running production workloads, now moves to maintenance mode, with most vector-search effort going into pg_vectorsearch.

That is the real signal for teams choosing a stack today. If you are on pgvectorscale, nothing breaks, but new features will land elsewhere. If you are evaluating Postgres-native vector search against a dedicated database, browse the open-source listings, the product directory and comparisons on TechLogHub, and treat PRISM as a strong candidate to benchmark in 2027 rather than a drop-in for this quarter.

FAQ

Is pg_vectorsearch a replacement for pgvector?

Not yet. It is alpha, and it ships its own vec32 and vec16 types that are binary-compatible with pgvector's vector and halfvec, so the two can run side by side. You can build a PRISM index on an existing pgvector column without rewriting the table.

Which PostgreSQL versions does pg_vectorsearch support?

PostgreSQL 18 or later, with development headers, a C11 compiler (GCC 11+ or Clang 14+) and the Meson build system.

How much faster is PRISM than HNSW?

In Tiger Data's 100M-vector test, PRISM built its index in 49 minutes versus 42 hours for HNSW on the same 512 GiB instance, with a 25 GB index versus 180 GB. Query p50 at 95% recall was 4 ms versus 8 ms. No throughput figures were published.

When should I keep using HNSW?

For small or fast-changing datasets that fit in memory. HNSW adds one vector at a time, while PRISM needs enough data to form clusters and currently needs manual rebalancing under heavy churn.

Does pg_vectorsearch support filtered vector search?

Not in the alpha. Streaming search that keeps producing candidates until a WHERE filter is satisfied is listed as a planned GA feature.

What happens to pgvectorscale?

Tiger Data says pgvectorscale is stable and runs production workloads, but it is entering maintenance mode while most vector-search development moves to pg_vectorsearch.

Benchmark it on your own embeddings first; a vendor chart is a hypothesis, not a migration plan.