Announcing pg_vectorsearch: Scalable Open-Source Vector Search in PostgreSQL

Tiger Data launches pg_vectorsearch, an open-source PostgreSQL extension whose PRISM index uses partitioning and compression instead of HNSW graphs to deliver faster vector queries with far less memory and quicker index builds.

TLDR: We are launching pg_vectorsearch, a new open-source PostgreSQL extension that makes vector search dramatically faster and more cost-efficient. Its new PRISM index uses partitioning and compression instead of HNSW's graph-based approach, delivering faster queries with a fraction of the memory and significantly faster index builds. At 100 million vectors, PRISM achieved 6 ms query latency on a machine with 4× less memory than HNSW, with index builds over 20× faster.

Vector search is more useful when it lives alongside the rest of your data. For RAG, semantic search, and recommendations, keeping vectors in PostgreSQL means you can join results with application data, update both in a single transaction, and use the SQL tools you already know. Plus, you don’t need to operate separate database systems and sync data between them.

pgvector has made this possible, with HNSW becoming the go-to vector index in PostgreSQL. But HNSW is memory hungry. Searching its graph involves repeated random reads, so good performance depends on keeping much of that graph in memory. In our benchmarks at 100 million vectors, the smallest machine on which HNSW finished building had 512 GB of RAM. Those resource demands can push teams out of the PostgreSQL they love and into a dedicated vector database, which requires fewer resources due to newer, partition-based indexing algorithms but forces your application to use a separate database only for vector search.

We built pg_vectorsearch so you can stay in PostgreSQL. It's a new open-source extension, currently in alpha, whose Partitioned Routing Index for Similarity Matching (PRISM) index delivers faster vector search with fewer resources than pgvector's HNSW. It’s more resource-efficient for both small and large workloads.

Meet Prism

PRISM brings a partition-based approach to PostgreSQL, similar to the approach used by newer dedicated vector search systems. Instead of connecting every vector to its neighbors in a graph, PRISM groups similar vectors into partitions and stores them as a list in a compressed format that is densely packed into database pages. When searching, it identifies the most relevant partitions and scans through their vectors. This has two advantages: the index is much smaller because it stores compressed vectors without graph connections, and searching is more efficient because the database reads data sequentially rather than jumping between locations in memory (or disk). Together, these improvements let PRISM deliver fast vector search with much less RAM, all within PostgreSQL, where your data already lives.

The difference is substantial. At 100 million vectors, PRISM builds and serves the index on a 128 GB machine and delivers 6 ms p50 query latency at 95% recall, compared with HNSW's 8 ms on a machine with four times more memory (512 GB!). Building the index is similarly faster: 1 hour 40 minutes with PRISM on the 128 GB box, versus 42 hours with HNSW on the 512 GB server. The benefits extend to smaller deployments: at 1 million vectors and 99% recall, PRISM delivers 15 ms latency on a 2 GB machine, while HNSW takes 392 ms on a machine with twice the memory (more than 23x slower).

Scaling vector search shouldn't have to mean leaving PostgreSQL. And staying in PostgreSQL gives you more than just vector search. You can combine semantic similarity with BM25 keyword ranking using pg_textsearch, filter by time, metadata, or hierarchical relationships, and join results with the rest of your application data. All using SQL, in a single database, without syncing data between separate systems.

Benchmarks

Every result in this post comes from our public benchmark tool. Recall is recall@10 against exact brute-force results. Both indexes ran with the same PostgreSQL configuration on the same instance types. All HNSW results use pgvector's 16-bit halfvec, which gave HNSW the best tradeoff between query performance and index size in our testing [1].

At 100 million vectors, PRISM runs on a machine HNSW can't even build on

We indexed 100 million Cohere embeddings on two AWS instances: an r8i.4xlarge with 16 vCPUs and 128 GiB of RAM, and an r8i.16xlarge with 64 vCPUs and 512 GiB, which costs four times as much per hour.

On the smaller machine, PRISM built the index in 1 hour 40 minutes and served queries at 99% recall in 21 ms. HNSW couldn't build there at all. On the larger machine, HNSW finished after 42 hours and served 95% recall in 8 ms, but we couldn't get it to 99% recall at a usable latency. PRISM built on the same large machine in 49 minutes and served 99% recall in 19 ms.

Instance Size

R8i.4xlarge (128 GB)

R8i.16xlarge (512 GB)

Algorithm

PRISM

HNSW

PRISM

HNSW

Relative hourly cost of that instance

Build time

1 h 40 min

Did not finish

49 min

42 hours

Index size

25 GB

180 GB

25 GB

180 GB

P50 Latency for 95% recall@10

6 ms

4 ms

8 ms

P50 Latency for 99% recall@10

21 ms

19 ms

not achieved

We also tried to “cheat” to help HNSW out. If HNSW can't be built on the small machine, maybe it can be built on the big one and then served from the small one. We'd never recommend this in production, since resizing means downtime and you'd be serving an index on hardware that can't rebuild it. We tried it anyway to see whether the shortcut exists. It doesn't. On the r8i.4xlarge, the moved HNSW index took over a second per query at 95% recall and couldn't reach 99% at all. At 100 million vectors, HNSW needs the large machine for queries as well.

At 1 million vectors, PRISM serves 99% recall on 2 GiB of RAM

Most teams don't have 100 million vectors, so we checked whether the pattern holds at a more common scale. We indexed 1 million vectors on a c8g.large with 4 GiB of RAM and a c8g.medium with 2 GiB.

On the c8g.large, PRISM built in about 3 minutes. HNSW took about 21.7 hours, because the graph doesn't fit in 4 GiB during construction and the build thrashes. Given that, we couldn’t realistically try HNSW on the smaller machine.

Instance Size

C8g.medium (2GB)

c8g.large (4 GB)

1M vectors

PRISM

HNSW

PRISM

HNSW

Build time

~3 min

Did not finish

~3.1 min

~21.7 h

Relative hourly cost of that instance

2Index size

280 MB

2.05 GB

P50 Latency for 95 % recall@10

9 ms

3 ms

122 ms

P50 Latency for 99% recall@10

15 ms

9 ms

392 ms

On the same 4 GiB machine, the PRISM index is about seven times smaller than HNSW's and answers queries about 40 times faster at the same recall. On half that memory, PRISM still serves 99% recall in 15 ms, while HNSW needs 392 ms on the bigger box.

Why and how it works

Why we moved away from graph indexes

This isn’t the first vector index we’ve built and open-sourced for PostgreSQL. In 2024, Tiger Data releasedpgvectorscale, which used a graph-based indexing algorithm inspired by Microsoft’s DiskANN research. We deliberately chose a disk-optimized design so that indexes could scale beyond available RAM. Our initial benchmarks were promising, but as adoption grew and we tested against a wider variety of datasets, particularly low-dimensional ones, we encountered a troubling problem: portions of the graph could become unreachable, causing recall to degrade. We searched the literature for a principled solution but couldn’t find one, and the heuristics we tried worked on some datasets but not others.

That’s a frustrating failure mode for a search index. When queries are slow, you can measure the problem and tune accordingly. But when recall degrades, you might not even notice until users start questioning the quality of their search results. And telling them to experiment with yet another set of tuning parameters isn’t the experience we want to provide.

Meanwhile, partitioned-list approaches reminiscent of IVFFlat were getting a second life, as advances in compression and optimization addressed many of their old limitations. More importantly, they offered stronger guarantees than we could achieve by patching a graph-based index. We came to believe they were a better foundation, and decided to start over.

With the introduction of pg_vectorsearch, we are shifting the majority of our vector-search development efforts to this new architecture. The existing pgvectorscale extension, which is stable and handling production workloads currently, will enter maintenance mode.

Scanning partitions beats walking a graph on modern CPUs

Google’s ScaNN for AlloyDB, Microsoft’s SPANN, and turbopuffer’s ANN engine have converged on the same approach: partition the vector space, compress the vectors, and scan nearby partitions efficiently with SIMD. The rest of this section explains why the industry has largely moved off of graphs, towards partitions, and how PRISM takes these learnings and applies them to a native Postgres index.

A big reason partitioned indexes can win comes down to how CPUs read memory. A graph search narrows the candidates quickly by hopping from node to linked node, but each hop's address comes from the node before it. The CPU can't prefetch an address it can't predict, so most hops miss the cache, and the core sits idle until memory answers. Faster distance math doesn't help much when most of the time goes to waiting. Once the graph spills to disk, those same hops become scattered reads. And every vector carries edges to its neighbors, which is part of why the graph is so large to begin with.

A partitioned index splits the vector space into clusters with k-means. Each cluster stores compressed vector codes and row IDs back to back. A query walks a small tree of cluster centroids, which the Postgres buffer cache keeps warm, to find the clusters nearest the query, then scans every vector in them. That scan reads memory in a straight line, so the prefetcher stays ahead of the CPU, and SIMD loops score many vectors per instruction. The limit becomes memory bandwidth, of which modern hardware has plenty.

New compression algorithms make those scans even cheaper because they replace full vectors with much smaller codes. PRISM stores each vector as a RaBitQ code of roughly one bit per dimension, so scanning a partition means moving and scoring far less data. Because compressed distances are approximate, indexes typically rerank promising candidates against the full vectors, which requires random reads from the table. RaBitQ's error bounds rule out candidates that can't be in the top results, so far fewer need that second look.

Partitioning also makes RaBitQ's error bounds tighter. Its error grows with the size of the vector it compresses, and a partitioned index compresses each vector's offset from its cluster's centroid, which is much smaller than the vector relative to the origin. HNSW has no centroid to subtract, so it can't get that benefit. It’s unusual but the index structure and compression reinforce each other and are not independent.

Partition boundaries create another problem: a vector near the edge of one cluster may be relevant to queries routed to a neighboring one. Scanning more partitions helps, and storing boundary vectors in more than one partition helps more directly, trading a little storage for recall. ScaNN's SOAR algorithm does this by “spilling” a vector into a second cluster in a geometry-aware way. PRISM implements this spilling technique as well.

Graphs still fit some workloads, especially small, fast-changing datasets. HNSW grows one vector at a time, while a partitioned index needs enough data to form meaningful clusters. That gap is narrowing as newer techniques let partitions split, merge, and rebalance as data changes, and it's where PRISM is headed next.

pg_vectorsearch today

This is the first public release of pg_vectorsearch, and we're calling it an alpha. The core works and you can test it on real data today, but there are gaps you should know about before you do.

What works today:

Creating an index. Index builds on a populated table, including parallel builds, and k-nearest-neighbor search with L2, inner product, and cosine distance.

pgvector compatibility. PRISM works with pgvector’s vector and halfvec data types. You can build a PRISM index directly on existing pgvector columns with no rewrites and no copies, and queries written with pgvector's operators work unchanged. But, pgvector is not a dependency: pg_vectorsearch ships its own vec32 and vec16 types so that it can operate independently.

Optimized distance computation works across a wide range of architectures. SIMD distance optimizations for AVX2, AVX-512, and NEON.

Simplified tuning. For queries, there is a single parameter to tune: prism.nprobe, the number of clusters a query scans. The default of 0 picks a value automatically to target roughly 95% recall.

Inserts and updates work now but heavy churn can cause recall drift without manual intervention. Right now, we don’t re-partition automatically under churn so the partitioning can become suboptimal. You can split oversized partitions manually by calling prism_rebalance or re-build the full index from scratch by calling REINDEX. We plan to remove the need for these manual steps in the future and handle drift automatically. For this version, we don't recommend creating the index on an empty table and filling it afterwards.

Delete operations work but don’t yet reuse space. Deletes are turned into tombstones by VACUUM so that they can be skipped by scans, but we don’t yet reuse the space inside index pages. You can run REINDEX to reclaim space.

PRISM is a native PostgreSQL index access method, so there's no separate service to run.

Planned for the GA release:

Automatic, incremental rebalancing. As mentioned above, currently you need to run manual steps to have the index repartition and rebalance under heavy churn. We plan to automate this.

Streaming search, with WHERE clauses filters alongside ORDER BY, streamed so the index keeps producing candidates until the filter is satisfied.

Hardening: testing for physical replication, backup and restore, and multi-client throughput.

Further out: parallel query execution, multi-column indexes for multi-tenant tables, disk reclamation during VACUUM, and a billion-vector benchmark.

CREATE EXTENSION pg_vectorsearch; CREATE TABLE documents ( id bigserial PRIMARY KEY, body text, embedding vec32(768) ); -- Load your data first. PRISM sizes the index from the row count at build time. CREATE INDEX ON documents USING prism (embedding vec32_l2_ops); SELECT id, body FROM documents ORDER BY embedding <-> $1 LIMIT 10;

If you already have a pgvector column, you can build the PRISM index on it directly. The column isn't rewritten or copied, and your existing queries keep using pgvector's operators:

CREATE EXTENSION pg_vectorsearch; CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);

Use vec32_cosine_ops or vec32_ip_ops for other distance functions, and the vec16_* operator classes for halfvec columns. The one setting most deployments touch is prism.nprobe, the number of partitions each query scans. The default of 0 picks a value automatically to target roughly 95% recall. Raise it for more recall at some cost in latency:

SET prism.nprobe = 40;

The repo's tuning guide covers the rest, and its README walks through migrating from an existing HNSW index.

pg_vectorsearch is open source under the PostgreSQL License. The alpha is the best time to shape where it goes, so run it against your own data and tell us where it falls short on GitHub. If your results disagree with ours, open an issue and we'll dig in.

[1]: pgvector's binary quantization shrinks HNSW further, but the index is still double the size of PRISM while recall drops sharply, and recovering it means reranking full vectors outside the index scan in a CTE. We couldn't get good recall at competitive speed that way, which matches results others have published.

TimescaleDB 2.27: Broader Vectorized Execution, Up to 160x More Efficient UPDATE/DELETE, and Smarter UPSERT Pruning