pg_vectorsearch Claims 6 ms at 100M Vectors. Filtered Queries Can Come Back Short

• Book: Database Playbook
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

---

If your RAG app keeps its embeddings in Postgres, the index behind it is probably pgvector's HNSW. pgvector's own README says HNSW "has slower build times and uses more memory" than its other index type, IVFFlat, in exchange for a better speed-recall trade-off.

On October 13, Tiger Data, the company behind TimescaleDB, announced pg_vectorsearch, an open-source Postgres extension with a new index called PRISM. Its headline: 6 ms median latency at 95% recall on 100 million vectors, on a machine where pgvector's HNSW build did not finish. On October 14 it drew a Hacker News thread.

Two things decide whether this matters to you yet. The numbers come from Tiger Data's own benchmark. And the alpha has a gap right where most RAG queries live: the WHERE clause.

What Tiger Data shipped

PRISM stands for Partitioned Routing Index for Similarity Matching, and it is a native Postgres index access method, so there is no separate service to run. Instead of HNSW's graph, it groups vectors into k-means clusters and, per the announcement, "stores each vector as a RaBitQ code of roughly one bit per dimension."

A query walks a centroid tree to the nearest clusters, scans their posting lists, filters candidates with RaBitQ error bounds, then reranks them with full-precision vectors from the table (README). The README describes it as "conceptually similar" to pgvector's IVFFlat.

The practical details, all from the README:

• It needs PostgreSQL 18 or later.
• It ships its own vec32 and vec16 types, and they are binary-compatible with pgvector's vector and halfvec.
• It can index an existing pgvector column without rewriting the table, and the two extensions can sit side by side.
• It is under the PostgreSQL License.

The pitch is one sentence in the announcement: "We built pg_vectorsearch so you can stay in PostgreSQL."

The numbers are Tiger Data's, so read the conditions

Every result in Tiger Data's announcement comes from its public benchmark tool, rekall. Recall is recall@10 against exact brute-force results, and every HNSW run used pgvector's halfvec. Here is the 100-million-vector run, on Cohere embeddings, as the post reports it:

Machine	Index	Build	Size	p50 @95%	p50 @99%
r8i.4xlarge (128 GB)	PRISM	1 h 40 min	25 GB	6 ms	21 ms
r8i.4xlarge (128 GB)	HNSW	did not finish	n/a	n/a	n/a
r8i.16xlarge (512 GB)	PRISM	49 min	25 GB	4 ms	19 ms
r8i.16xlarge (512 GB)	HNSW	42 h	180 GB	8 ms	not reached

At 1 million vectors, the same post reports PRISM at 15 ms median for 99% recall on a 2 GB c8g.medium, against 392 ms for HNSW on a 4 GB c8g.large. It says the HNSW build on the 4 GB machine took about 21.7 hours and thrashed.

What the announcement doesn't give you: the dimensionality of either dataset, throughput (queries per second), or a direct IVFFlat comparison. Multi-client throughput testing is listed as still pending. In the HN thread, one commenter asked for exactly that: "qps and precision/recall, please." I haven't run pg_vectorsearch myself, so treat the table as the vendor's claim, which rekall lets you check on your own data.

What the alpha doesn't do yet

Tiger Data is upfront about this. "This is the first public release of pg_vectorsearch, and we're calling it an alpha," the announcement says, and the 0.1.0-rc1 release notes call it "alpha quality and meant for testing, not production." The known issues in those notes are the part to read before you plan anything:

• Filtered queries can return fewer rows than LIMIT. If the rows that pass your WHERE aren't among the candidates the scan ranked, it doesn't look further (issue #188). A multi-tenant query like WHERE tenant_id = 7 ... LIMIT 10 can come back with fewer than 10 rows.
• Large ordered scans can return partial results without an error. With no LIMIT, or a LIMIT larger than work_mem lets it rank, you get only what that budget covers. Raising work_mem fixes the budget case.
• At most 1,968 dimensions, and no unlogged tables or expression indexes.
• Upgrades between prereleases may not work, so plan to drop and recreate the extension and its indexes.

The announcement adds the rest. There is no automatic rebalancing, so recall can drift under heavy churn until you run prism_rebalance or REINDEX. Space from deleted rows isn't reclaimed until REINDEX, and replication and backup/restore testing is still pending. Filtered "streaming search" is planned for GA.

The dimension cap is the one to check first. OpenAI's text-embedding-3-large returns 3,072 dimensions by default (OpenAI docs), and pgvector's HNSW can index halfvec up to 4,000 (pgvector README). If that's your setup, you'd need to shorten the vectors before PRISM could index them: re-embed with OpenAI's dimensions parameter, or truncate the stored vectors and re-normalize, which OpenAI's guide also describes.

pgvectorscale moves to maintenance mode

If you adopted Tiger Data's earlier extension, pgvectorscale, this is the news for you. Tiger Data's announcement says it is stable and runs production workloads, but will enter maintenance mode, and that its DiskANN-inspired graph index could lose recall on low-dimensional datasets. A pgvectorscale author said the same in the HN thread.

The post doesn't say what pgvectorscale users should do next. As of October 14, the pgvectorscale README carries no maintenance notice, and Tiger Cloud's extension list still includes it. The announcement doesn't mention Tiger Cloud support for pg_vectorsearch, and a commenter in the HN thread noted it isn't on managed providers' extension lists yet.

Try it next to HNSW, on a copy

You need Postgres 18 for this anyway, so do it on a staging copy of the table, not your production database. The README shows indexing an existing pgvector column directly. Pick the operator class that matches your column type and distance: vec32_* for vector, vec16_* for halfvec, with _l2_ops, _ip_ops or _cosine_ops.

CREATE EXTENSION pg_vectorsearch;

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

-- 40 is the README's example value.
-- 0 = auto (~0.95 recall); raise for recall,
-- lower for speed.
SET prism.nprobe = 40;

On the copy, drop the HNSW index so the planner can only pick PRISM, then confirm it does:

EXPLAIN
SELECT id FROM documents
ORDER BY embedding <=> (
  SELECT embedding FROM documents WHERE id = 1
)
LIMIT 10;

For recall, run the same query with index scans off, which gives you the exact top 10, and compare the two lists of IDs:

BEGIN;
SET LOCAL enable_indexscan = off;
SET LOCAL enable_indexonlyscan = off;
SELECT id FROM documents
ORDER BY embedding <=> (
  SELECT embedding FROM documents WHERE id = 1
)
LIMIT 10;
ROLLBACK;

Do that for a few hundred real queries, including your filtered ones, before you trust a number. Short results on filtered queries are issue #188, not your setup.

So, would you switch?

Vectors that fit in RAM, with HNSW fast enough? The alpha gives you little reason to move today. If your HNSW builds take a day, or your index no longer fits in memory, it is worth a weekend on a copy. Selective WHERE filters, like a per-tenant query, are where the alpha comes back short, so those are the queries to watch when GA lands.

What's stopping you: the Postgres 18 upgrade, the filtering gap, or your managed provider's extension list?

---

If this was useful

Picking between HNSW, IVFFlat and a new index type is the same call as picking a store: you trade memory, build time and query shape against each other, and the benchmark only tells you about someone else's data. The Database Playbook walks through those trade-offs for Postgres, SQLite, Redis, DynamoDB and the rest, so you can make that call for your own system.

I also build Hermes IDE (GitHub), free and source-available for macOS, Windows and Linux, where each coding-agent task can run on its own branch and worktree. That helps if you hand an experiment like this one to an agent. It's my project, so weigh that.