pg_vectorsearch vs pgvector HNSW: 42 Hours vs 49 Minutes. Here's the Catch

An independent review of Tiger Data's pg_vectorsearch extension found that its PRISM index built a 100-million-vector index in 49 minutes versus 42 hours for pgvector's HNSW on the same 64 vCPU, 512 GiB machine, and answered queries at roughly half the latency. The analysis cautions that the build-time comparison is tilted by HNSW's non-default ef_construction=200 setting and unpublished maintenance_work_mem, and that the extension remains alpha and unsuitable for production.

On a 64 vCPU, 512 GiB machine, pgvector took 42 hours to build an HNSW index over 100 million vectors. On the same box, Timescale's new pg vectorsearch extension built its index in 49 minutes and answered queries in half the time. Those are the numbers in the launch post https://www.tigerdata.com/blog/announcing-pg vectorsearch-scalable-open-source-vector-search-postgresql from Tiger Data formerly Timescale , published October 13, 2026. If you run RAG on Postgres, that headline is hard to ignore. I went through the post, the repo https://github.com/timescale/pg vectorsearch , the tuning docs, the benchmark tool's config files and the Hacker News thread https://news.ycombinator.com/item?id=50086165 to see how far the pg vectorsearch vs pgvector claim holds. Short answer: the query-side win is real and big. The build-time comparison is tilted, and the extension is still alpha, so production is off the table for now. The extension adds a new index access method called PRISM Partitioned Routing Index for Similarity Matching . The README calls it "conceptually similar to pgvector's IVFFlat", which is the clearest way to think about it. It's a partition index: That last part explains most of the memory difference. HNSW has to keep a big graph in memory to be fast, while PRISM only keeps a small tree there and scans compact posting lists for the rest. It also reads pgvector's types. vec32 and vec16 are binary-compatible with vector and halfvec , so you can put a PRISM index on an existing table: CREATE EXTENSION pg vectorsearch; CREATE INDEX documents embedding prism ON documents USING prism embedding vec32 cosine ops ; SET prism.nprobe = 40; -- 0 = auto, roughly 0.95 recall All figures are p50 latency at recall@10 against brute force, from the launch post. HNSW ran on pgvector's 16-bit halfvec . | | PRISM, r8i.4xlarge 128 GiB | PRISM, r8i.16xlarge 512 GiB | HNSW, r8i.16xlarge 512 GiB | |---|---|---|---| | Build time | 1 h 40 min | 49 min | 42 h | | Index size | 25 GB | 25 GB | 180 GB | | p50 @ 95% recall | 6 ms | 4 ms | 8 ms | | p50 @ 99% recall | 21 ms | 19 ms | not reached | HNSW didn't finish building on the 128 GiB box. When they moved the index built on the big machine over to it, queries took over a second at 95% recall and never reached 99%. | | PRISM, c8g.medium 2 GiB | PRISM, c8g.large 4 GiB | HNSW, c8g.large 4 GiB | |---|---|---|---| | Build time | ~3 min | ~3.1 min | ~21.7 h | | Index size | 280 MB | 280 MB | 2.05 GB | | p50 @ 95% recall | 9 ms | 3 ms | 122 ms | | p50 @ 99% recall | 15 ms | 9 ms | 392 ms | HNSW wasn't really tried on the 2 GiB box; the post says they "couldn't realistically try" it there, and the table marks it "did not finish". The headline "6 ms at 100M on 4x less memory" is the 128 GiB PRISM number against the 512 GiB HNSW number. I think that's fair: both hit 95% recall, and one machine costs a quarter of the other. Start with the HNSW build settings. Tiger Data's benchmark tool, rekall https://github.com/timescale/rekall , ships an HNSW config hnsw-m16.toml https://github.com/timescale/rekall/blob/main/benchmarks/indexes/hnsw-m16.toml with m = 16 and ef construction = 200 . pgvector's default ef construction is 64. Building with 200 buys a better graph and costs a lot more time. Reasonable if you're chasing 99% recall, but it inflates the build-time gap. The post doesn't say which config produced the published table, so I'm reading the repo, not the run. The post also doesn't publish maintenance work mem, and pgvector's README https://github.com/pgvector/pgvector is blunt about why that matters. Once the graph stops fitting in maintenance work mem , you get hnsw graph no longer fits into maintenance work mem after 100000 tuples and the build "will take significantly more time". A 2.05 GB HNSW index on a 4 GiB machine is going to hit that wall, and a 21.7 h build for 1M vectors is what hitting it looks like. I wouldn't call that normal HNSW performance. Same story for the 122 ms queries: the index doesn't fit in RAM next to the heap, so you're reading from disk. The numbers aren't dishonest, though. "HNSW falls over when it doesn't fit in memory" is exactly the point Tiger Data is making. But if your HNSW index already fits in RAM with headroom, the 1M table doesn't describe your setup. Then there's what the post leaves out. No QPS, no p99, no concurrency multi-client throughput testing is listed as GA work , no filtered search, no IVFFlat numbers even though the README compares PRISM to IVFFlat, and no published embedding dimension. Filtered search is where people actually suffer with pgvector, and PRISM's answer today is basic: per the tuning docs, the executor applies your WHERE clause after the index has emitted its top-k, and the scan inflates k based on estimated selectivity. Filters that are anti-correlated with vector distance can still return too few rows. The docs suggest a partial index on the filter. Streaming search with WHERE filters is on the GA roadmap. On HN, esafak asked the obvious thing: "Shouldn't you lead with your benchmarks if you're fast? qps and precision/recall, please." jascha eng replied that the benchmarks are in the post and the suite is open source. Both are right. They're still vendor numbers, and I haven't seen anyone outside Tiger Data publish a rerun yet. pgvectorscale, Tiger Data's 2024 DiskANN-style index, "will enter maintenance mode," per the launch post. On HN, Tiger Data CTO mfreed said parts of pgvectorscale's graph could become unreachable and degrade recall, and when they couldn't find a fix they decided to start over with a partition index. So the vendor that told you two years ago that its graph index was the answer is now telling you graph indexes are the problem. They might be right. They also showed you how fast a Postgres vector extension can go from flagship to maintenance mode. On top of that, the practical blockers: CALL prism rebalance 'items idx' ; splits them in place, but only on flat, single-level indexes built with centroid fastscan = off . The default CREATE INDEX doesn't produce that shape, so for a default-built index the fix is a full REINDEX , which rewrites the whole index. A rebalance also leaves replaced lists on disk until the next auto falls back to a slower layout past that. On HN, devy said "PRISM caps at 1968 dimensions"; I couldn't find a hard cap in the docs. If you use 2048-dim embeddings VoyageAI offers them , test before you plan on it. If HNSW builds are killing you, fix the build before you change extensions. From the pgvector docs: SET maintenance work mem = '8GB'; -- size it so the graph fits SET max parallel maintenance workers = 7; -- plus leader CREATE INDEX ON items USING hnsw embedding::halfvec 768 halfvec cosine ops ; Use halfvec it halves the index and is what Tiger Data benchmarked against . Leave ef construction at 64 unless you've measured that you need more. If filtered queries return too few rows, turn on hnsw.iterative scan pgvector 0.8.0+; current release is v0.8.7 . My take: pg vectorsearch is the most interesting thing to happen to Postgres vector search since HNSW landed in pgvector. VectorChord took the same route of clustering plus quantized vectors, and its own benchmark https://docs.vectorchord.ai/vectorchord/benchmark/pgvector.html says its QPS "could be twice that of pgvector" at equivalent recall on GIST 1M 960 dims . That's a vendor number too. Still, when two separate teams build partition indexes and both beat HNSW, I'm inclined to believe the direction. Try it now, on a replica or a staging box, if: Stay on pgvector HNSW if: WHERE tenant id = ... filters and can't add a partial index per tenant Revisit at GA, when filtered streaming search and automatic, incremental rebalancing are supposed to ship. Until then, 42 hours vs 49 minutes is a great slide and a bad reason to migrate production. What do you run vector search on right now: pgvector, VectorChord, pgvectorscale, or a dedicated vector DB like Qdrant? And if you've rerun rekall on your own hardware, did the numbers hold up? Tell me in the comments.