By ByteBot
Tiger Data dropped pg_vectorsearch alpha on October 13. Its new PRISM index built a 100-million-vector index in 49 minutes. pgvector’s HNSW needed 42 hours for the same job. Both run in Postgres. One of them is no longer the right answer for large-scale vector workloads.
Why HNSW Runs Out of Road at Scale
pgvector’s HNSW index works by keeping its entire graph in RAM. For datasets under 10 million vectors that’s fine. Past that, you’re either buying expensive memory, waiting for multi-hour index builds, or accepting degraded recall while you figure out the next step. pgvectorscale helped push the ceiling higher with its DiskANN implementation — but that extension is now entering maintenance mode. pg_vectorsearch is the replacement Tiger Data is betting on.
PRISM (Partitioned Routing Index for Similarity Matching) takes a different architectural approach. Instead of a graph, it builds a hierarchical centroid tree that partitions vectors into clusters. Vectors themselves are stored as RaBitQ codes — roughly one bit per dimension — in posting lists laid out for SIMD distance computation. The centroid tree stays warm in Postgres’s buffer cache. No external service, no separate daemon, no data synchronization headache: it’s a native Postgres index access method.
The memory footprint is 4x smaller than HNSW. The build that took HNSW 42 hours finished in 49 minutes. At 100 million vectors and 95% recall, query latency sits at 4–6 milliseconds. Those numbers come from Tiger Data’s own benchmarks with a single client — multi-client throughput testing is still pending — but even discounting for vendor optimism, the architectural difference is real.
Dropping In Without Breaking Your Schema
pg_vectorsearch ships vec32 and vec16 types that are binary-compatible with pgvector’s vector and halfvec. You do not need to rewrite your table or migrate your data. Both extensions can live in the same database. Install the extension, build a PRISM index on your existing column, and test it alongside your current index before committing to a cutover.
CREATE EXTENSION pg_vectorsearch;
-- Index an existing pgvector column, no table rewrite needed
CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);
-- Query syntax stays the same
SELECT id, content
FROM documents
ORDER BY embedding <-> '[0.1, 0.2, ...]'::vec32
LIMIT 10;That’s a low-friction migration path for teams already on pgvector. No forced cutover, no dual-write complexity — just a parallel index you can test against your real workload.
The Part the Announcement Buries
Filtered queries can come back short. If your query includes a WHERE clause — WHERE tenant_id = 7 LIMIT 10, for instance — PRISM may return fewer than 10 rows if the rows matching your filter aren’t among the candidates it ranked. It doesn’t search further when it runs out of candidates. This is tracked as Issue #188 on the repository.
That gap matters because most production RAG and agent memory queries combine vector similarity with metadata filters. Scoping a semantic search to a specific user, document type, or date range is not an edge case — it’s the default pattern. PRISM’s current limitation sits exactly where real queries run.
Tiger Data is explicit: this is alpha software for testing, not production. The filtered-query problem, a 1,968-dimension cap, and the PostgreSQL 18 requirement all point to the same verdict — evaluate it now, do not route live traffic through it yet.
What pgvectorscale Users Should Do Now
Tiger Data is shifting new feature development to pg_vectorsearch and moving pgvectorscale into maintenance mode. Bug fixes and security patches will continue, but the product roadmap belongs to pg_vectorsearch from here. If you’re running pgvectorscale today, you’re not on a dead end — but you can see the migration on-ramp from where you’re standing.
The practical path: keep pgvectorscale in production, stand up pg_vectorsearch in staging, and run your actual query patterns against it. Watch for GA. The binary type compatibility between the two extensions simplifies the migration, but verify your specific workload — especially any queries with WHERE clauses — before you commit.
When Does pg_vectorsearch Actually Matter?
If your vector dataset stays under 10–20 million records and HNSW builds in a reasonable time, pgvector HNSW is still the right choice. It’s production-hardened, well-documented, and ships on every managed Postgres platform. pg_vectorsearch gives you no reason to disrupt a working stack today.
The threshold where pg_vectorsearch becomes worth evaluating seriously: your HNSW builds take hours, you’re approaching memory limits, or you’re projecting past 50 million vectors within the next year. That’s the workload PRISM was designed for — and based on the benchmark numbers, Tiger Data has a credible answer. The full announcement and the GitHub repository have the technical breakdown. The alpha is available now for PostgreSQL 18+. When Issue #188 closes, the case for production adoption gets a lot stronger.
