Faster Postgres Vector Indexes: What PRISM Means for RAG

A RAG project rarely fails because the prompt was wrong. It fails because the index takes hours to rebuild, the graph will not fit in memory on a machine the client agreed to pay for, and nobody can answer the question “how long until search works again?” That maintenance tax is the real reason teams start shopping for a dedicated vector database — and it is the exact cost a new Postgres extension is now attacking.

On October 13, Tiger Data (the company formerly known as Timescale) released pg_vectorsearch, an open-source PostgreSQL extension whose new PRISM index replaces HNSW’s graph walk with partitions and compressed vectors. It is alpha, it requires PostgreSQL 18, and it is not something to put in front of a client this month. But it changes the arithmetic on a decision most agency engineering teams are about to make.

Index maintenance is the cost nobody budgets for

Teams budget for embeddings. Very few budget for what happens when the embedding model is upgraded, the corpus doubles, or a new filter column arrives. Each of those is a rebuild, and a rebuild is the moment a “cheap” in-database vector search shows its real price: memory, build hours, and a maintenance window the client has to accept.

In PostgreSQL that pain shows up in two places. HNSW is memory-hungry because a query hops between graph nodes, reading unpredictably, so most of the graph wants to stay resident. And approximate indexes apply filters after the scan, which quietly returns fewer rows than the LIMIT asks for. We covered the second problem, and the storage-side fixes, in pgvector at scale: cut index size and re-embedding costs — the recall cliff under selective filters is the single most common bug we see in client RAG builds.

What PRISM actually changes

PRISM stands for Partitioned Routing Index for Similarity Matching. Rather than connecting every vector to its neighbours, it groups similar vectors into partitions and stores them compressed and densely packed into database pages. A query routes to the nearest partitions and scans them sequentially, which is friendlier to the CPU than chasing pointers around a graph.

Three properties matter more than the algorithm:

• It is a native index access method, not a service. You create it like any other index, and backups, replication and SQL tooling keep working. There is no second database to sync.
• It indexes existing pgvector columns. No table rewrite, no data copy, and queries written with pgvector’s distance operators keep working. That makes it testable on a copy of production rather than a migration project.
• One tuning knob. prism.nprobe sets how many partitions a query scans; the default of 0 targets roughly 95% recall.

The benchmark numbers, read honestly

Tiger Data published its own measurements, using its public benchmark tool, on 100 million Cohere embeddings:

• On a 128 GiB instance, PRISM built the index in 1 hour 40 minutes and served 95% recall at 6 ms p50. HNSW did not finish building on that machine at all.
• On a 512 GiB instance costing four times as much per hour, PRISM built in 49 minutes and served 95% recall at 4 ms; HNSW took 42 hours for 8 ms at the same recall and never reached 99% at a usable latency.
• Index size: 25 GB for PRISM against 180 GB for HNSW on the same data.

At one million vectors the pattern repeats: about three minutes to build a 280 MB index, versus roughly 21.7 hours for HNSW on the same 4 GiB machine.

Read the table the way a vendor benchmark deserves to be read. The latency win on equal hardware is real but modest — 4 ms against 8 ms is not a different league. The story is build time and memory footprint. A build that goes from 42 hours to under an hour changes what a re-embedding project looks like: it becomes an afternoon instead of a launch-blocking migration, which is precisely the risk that makes clients hesitate to change embedding models at all.

Where it does not fit yet

This is an alpha release, and the gaps are documented rather than hidden:

• PostgreSQL 18 or later. Most production clusters are still on 15 through 17, so for most clients this is not a drop-in.
• No filtered streaming search yet. Queries that combine a WHERE clause with ORDER BY distance are planned for general availability. Until then, filtering behaves the way it does with HNSW: post-scan, with the recall cliff that implies. Multi-tenant tables, where every query filters by tenant, are the worst case.
• Churn is manual. Heavy inserts and updates can degrade partitioning; the fix today is calling prism_rebalance or rebuilding with REINDEX. Building the index on an empty table and filling it afterwards is explicitly discouraged.
• Deletes leave tombstones until you reindex, and the extension refuses unlogged tables and expression indexes and caps indexed dimensions at 1,968.

There is also a roadmap signal worth noting: Tiger Data says the older pgvectorscale extension moves into maintenance mode. If a client adopted pgvectorscale last year on the strength of its Pinecone-comparison benchmarks, the vendor’s development effort has just moved elsewhere.

What to do this quarter

The practical response is not “migrate.” It is to stop treating the vector index as infrastructure you inherit and start treating it as a rebuildable artifact you measure.

1. Inventory the facts you do not have: row counts, dimensions, embedding model version per column, and the last measured build time. Most teams can answer two of four.
2. Time a rebuild on a copy. Not on production, and not from memory. The number you get is the number that decides whether you need PRISM, a bigger instance, or nothing at all.
3. Fix recall measurement before you tune anything. A golden set is what makes a before/after comparison meaningful, and it is the step most teams skip — see build a golden set before you tune retrieval.
4. Keep HNSW as the production default and run PRISM as a benchmark target on real client data. Alpha code earns its way in with numbers, not with a vendor chart.
5. Document the cutover path for a model swap: new column, full backfill, index rebuild, then switch. Embeddings from different models are not comparable, so half-migrated tables are a silent quality bug.

Whether you stay on HNSW or move to a partition-based index, the strategic point is the same one behind why your RAG stack probably does not need a managed vector database: the cheapest architecture is the one where vectors live next to the data they describe and can be rebuilt on demand. Postgres just got a better answer to “on demand.”

If you are weighing that migration — or you inherited a RAG build nobody can rebuild — have us benchmark your vector index against your own data before you move anything. We would rather find the bottleneck on a test copy than in a client demo.