A couple preliminary findings if you are considering adopting this extension to replace your previous pgvector's HNSW indexing.
- pg_vectorsearch uses a quantized IVF index called PRISM. PRISM caps at 1968 dimensions for vectors. If your previous HNSW index has more dimensions than that, you're SOL (at least for now until they fix that).
- pg_vectorsearch requires Postgres version 18 or above. If you run PG versions below that you need to migrate your database first. Many legacy PG production environment are way dated on PG 14 or 15, migration is prohibitively high cost to just try this out.
- pg_vectorsearch shipped yesterday and it's obviously alpha. Hasn't been battle tested in production environments outside of Timescale's. Also since it's so new, it isn't on Azure's allowed-extension list or any other Hyperscale's managed PG instances' allowed extension list. It takes time to graduate from alpha and mature. So if you run managaed PG instances from hyperscaler's cloud, you're SOL (at least for now until this matures into those ecosystems) or you have to migrate to a PG 18 self-hosted.
Re: Max dimensions: You can truncate your input vector specifically for the index, and then when querying, you can query the index via a truncated vector and perform an additional full-length comparison as well.
For example: (taken from a project I'm currently working on)
```
SELECT *
FROM report_embeddings a
INNER JOIN report_embeddings b
ON (
subvector(a.embedding, 1, 768)::vector(768) <->
subvector(b.embedding, 1, 768)::vector(768)
) < $1
AND b.id != a.id
WHERE a.id = $2
AND a.embedding <-> b.embedding < $1
```
In this example, I truncate the embedding to 768 dimensions for the index and the lookup, (see the INNER JOIN) but do an additional full vector comparison as well. (in the WHERE clause)
This performs a fast but less accurate lookup into the index, and then only does the non-indexed full vector check for the matched results.
I have used pgvector on an Azure DB. It did a "reasonable" job. I am not an expert on HNSW vs PRISM but because it is all backward compatible, I am curious why they didn't just send a PR to the pgvector folks?
Like, I would love to learn more about the design process that led to a whole new thing. I am sure the decision was not taken lightly, but the README is very thin on the details for why anyone should go through the troubles above, at least in the making of it.
Fair question. When we built our first vector extension, pgvectorscale, we actually reached out to pgvector's author to see if they'd be interested in supporting additional index types (at the time, DiskANN-based), so we could contribute our work directly to pgvector. At the time, their preference seemed to be to focus on the existing index types rather than expand the project in that direction. We respected that decision and went ahead with a separate extension.
But one of the great things about open source and PostgreSQL's extension architecture is that these projects can coexist! pg_vectorsearch can work directly with pgvector's existing data types, so developers can use either index.
Main pg_vectorsearch contributor here. There are multiple reasons why simply “sending a PR” is more difficult than it sounds.
As a company, we want to move at a different pace and try things that a project like pgvector wouldn’t necessarily allow (and rightfully so). pg_vectorsearch is alpha-level software, while pgvector is stable. Releasing early is a way to make it available to the community sooner and getting feedback.
Then there are all kinds of technical reasons: different architectures, different implementation choices, etc. There's also the freedom to try new things and going in completely different directions.
A lot of great questions, feedback, and already some PR contributions today about pg_vectorsearch. I've written a short technical deep dive into the architecture of its PRISM index to answer some, thought I'd share:
I'm currently running VectorChord and I love it - with a fast backing disk, it's cut my postgres cost in half. Excited to see competition in low-RAM vector index tools. RAMageddon seems to be creating incentives to find more ways to take advantage of how fast modern nvme drives are!
Summary: We weren't happy with the unpredictable recall performance of pgvectorscale (and couldn't find a way to fix that in the literature) and decided that moving away from graph-algorithms to partition-based ones was a better long-term approach.
You can check two projects on top of sqlite using paxos and implement reciprocal rank fusion (RRF) and distribution-based fusion score (DBSF) on top of sqlite with sqlite's FTS and sqlite-vec extensions.
Just you need to remember sqlite support single writer at a time so both needs to work with that limitation. PostgreSQL uses MVCC, so performance for concurrent writes from multiple clients might be better. Did not do benchmark against it so cannot say.
Well you can always move to tiger cloud if you want it managed :)
And this is PostgreSQL licensed just like our pg_textsearch which has been adopted to Googles AlloyDB and microsofts HorizonDB already, so there is hope!
Oh interesting… I have the entire SEC database to index (only indexing the text in a sliver of it at the moment) and use tsvector and I could use something faster.
Ah, I remember now that ParadeDB's pitch was doing hybrid search by using pgvector with keyword rankings from pg_search. Never got the chance to try it.
> 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.
We're also the authors behind pgvectorscale. From our blog post:
This isn’t the first vector index we’ve built and open-sourced for PostgreSQL. In 2024, Tiger Data released pgvectorscale, 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.
We're currently use pgvectorscale. Some questions:
- Will pg_vectorsearch eventually also support vectors bigger than 1968 dimensions? E.g. VoyageAI can create embeddings with 2048 dimensions (but we don't actually need that at the moment, only 1024).
- Why did you choose C this time and not Rust, as you did with pgvectorscale?
- Why did you not just extend pgvectorscale with another index type instead of creating a whole new extensions?
It’s there. Titled “Announcing pg_vectorsearch: Scalable Open-Source Vector Search in PostgreSQL”. In paragraph: “ The result: an index that is significantly faster”
A couple preliminary findings if you are considering adopting this extension to replace your previous pgvector's HNSW indexing.
- pg_vectorsearch uses a quantized IVF index called PRISM. PRISM caps at 1968 dimensions for vectors. If your previous HNSW index has more dimensions than that, you're SOL (at least for now until they fix that).
- pg_vectorsearch requires Postgres version 18 or above. If you run PG versions below that you need to migrate your database first. Many legacy PG production environment are way dated on PG 14 or 15, migration is prohibitively high cost to just try this out.
- pg_vectorsearch shipped yesterday and it's obviously alpha. Hasn't been battle tested in production environments outside of Timescale's. Also since it's so new, it isn't on Azure's allowed-extension list or any other Hyperscale's managed PG instances' allowed extension list. It takes time to graduate from alpha and mature. So if you run managaed PG instances from hyperscaler's cloud, you're SOL (at least for now until this matures into those ecosystems) or you have to migrate to a PG 18 self-hosted.
Re: Max dimensions: You can truncate your input vector specifically for the index, and then when querying, you can query the index via a truncated vector and perform an additional full-length comparison as well.
For example: (taken from a project I'm currently working on)
```
SELECT *
FROM report_embeddings a
INNER JOIN report_embeddings b
subvector(b.embedding, 1, 768)::vector(768) WHERE a.id = $2 ```In this example, I truncate the embedding to 768 dimensions for the index and the lookup, (see the INNER JOIN) but do an additional full vector comparison as well. (in the WHERE clause)
This performs a fast but less accurate lookup into the index, and then only does the non-indexed full vector check for the matched results.
That’s only going to work on an MRL embedding.
I have used pgvector on an Azure DB. It did a "reasonable" job. I am not an expert on HNSW vs PRISM but because it is all backward compatible, I am curious why they didn't just send a PR to the pgvector folks?
Like, I would love to learn more about the design process that led to a whole new thing. I am sure the decision was not taken lightly, but the README is very thin on the details for why anyone should go through the troubles above, at least in the making of it.
Fair question. When we built our first vector extension, pgvectorscale, we actually reached out to pgvector's author to see if they'd be interested in supporting additional index types (at the time, DiskANN-based), so we could contribute our work directly to pgvector. At the time, their preference seemed to be to focus on the existing index types rather than expand the project in that direction. We respected that decision and went ahead with a separate extension.
But one of the great things about open source and PostgreSQL's extension architecture is that these projects can coexist! pg_vectorsearch can work directly with pgvector's existing data types, so developers can use either index.
Main pg_vectorsearch contributor here. There are multiple reasons why simply “sending a PR” is more difficult than it sounds.
As a company, we want to move at a different pace and try things that a project like pgvector wouldn’t necessarily allow (and rightfully so). pg_vectorsearch is alpha-level software, while pgvector is stable. Releasing early is a way to make it available to the community sooner and getting feedback.
Then there are all kinds of technical reasons: different architectures, different implementation choices, etc. There's also the freedom to try new things and going in completely different directions.
"Just sending a PR" is not that easy
Points 2 and 3 would probably apply to every interesting bleeding-edge Postgres extension out there.
so basically you should use Qdrant anyway lmao :p
[Tiger Data CTO here]
A lot of great questions, feedback, and already some PR contributions today about pg_vectorsearch. I've written a short technical deep dive into the architecture of its PRISM index to answer some, thought I'd share:
https://www.linkedin.com/pulse/inside-pgvectorsearch-archite...
I'm currently running VectorChord and I love it - with a fast backing disk, it's cut my postgres cost in half. Excited to see competition in low-RAM vector index tools. RAMageddon seems to be creating incentives to find more ways to take advantage of how fast modern nvme drives are!
I am the main contributor of pg_vectorsearch. If you try both, let us know about your experience and how we can improve.
Does it support filtering though?
Edit: post filtering only
I don't understand how people are efficiently implementing tenant/user/permission scopes with these indexes.
Checks notes, one dayabase per client, per user, per project ... etc
Partitioning is the easy bit I think, and falls out naturally from Postgres.
But how are people doing recency biasing with vector databases?
All of our approaches are either expensive or super hacky.
Multi-column indexes for multi-tenant tables is planned for a future release.
LanceDB supports push down and list/array membership through DataFusion.
Can’t wait to try this. Have a project where speed matters and still want to have a nice and simple DX with everything in postgres
Didn't these guys also write pgvectorscale which seems to be unmaintained now ? Why a new index instead of adding onto or improving pgvectorscale?
(pgvectorscale author here)
We address that directly in the blog post: https://www.tigerdata.com/blog/announcing-pg_vectorsearch-sc...
Summary: We weren't happy with the unpredictable recall performance of pgvectorscale (and couldn't find a way to fix that in the literature) and decided that moving away from graph-algorithms to partition-based ones was a better long-term approach.
It would be so awesome if SQLite supported anything along these lines.
You can check two projects on top of sqlite using paxos and implement reciprocal rank fusion (RRF) and distribution-based fusion score (DBSF) on top of sqlite with sqlite's FTS and sqlite-vec extensions.
Project zaxonlite: https://github.com/insanai/zaxonlite
Project sqlodin: https://github.com/insanai/sqlodin
Just you need to remember sqlite support single writer at a time so both needs to work with that limitation. PostgreSQL uses MVCC, so performance for concurrent writes from multiple clients might be better. Did not do benchmark against it so cannot say.
For what it's worth, DuckDB does. See: https://duckdb.org/docs/current/core_extensions/vss
There's a few, even an official extension called Vec1.
Interesting, I see no mention of support for bit precision and hammer distance operator which supposed to be much faster and storage efficient
Dark side of the PRISM! The image on the repo 100% inspired by Dark Side of The Moon by Pink Floyd.
SynthID reports it being generated by AI
Sadly if cloud providers don't offer it on managed postgres then not many people can use it...
Well you can always move to tiger cloud if you want it managed :) And this is PostgreSQL licensed just like our pg_textsearch which has been adopted to Googles AlloyDB and microsofts HorizonDB already, so there is hope!
I'm curious how it compares to `pg_search` https://www.paradedb.com/blog/introducing-search
Oh interesting… I have the entire SEC database to index (only indexing the text in a sliver of it at the moment) and use tsvector and I could use something faster.
unrelated! full-text search vs vector search, and this has a more permissive license.
Ah, I remember now that ParadeDB's pitch was doing hybrid search by using pgvector with keyword rankings from pg_search. Never got the chance to try it.
Sometimes you want both. I wonder if there is a postgresql reranker…
(Tiger data employee fwiw)
We have an alternative full-text search extension as well, pg_textsearch that's completely open source that supports hybrid re-ranking
Here's a blog on it (i linked to the section on hybrid search, there's a code snippet for you in there)
https://www.tigerdata.com/blog/introducing-pg_textsearch-tru...
We're big fans of extending Postgres for more and more usecases
How does it compare to Roar graph? https://github.com/matchyc/RoarGraph
from the accompanying blog post: https://www.tigerdata.com/blog/announcing-pg_vectorsearch-sc...
> 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.
Btw, I do work for Tiger Data/timescale, but am not at all associated with this team. I just found this release really exciting.
I sent the thread to Erik (the main contributor) though, so if you have feedback or questions, good chance that he'll see it.
How does this compare to pgvectorscale?
We're also the authors behind pgvectorscale. From our blog post:
This isn’t the first vector index we’ve built and open-sourced for PostgreSQL. In 2024, Tiger Data released pgvectorscale, 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.
Interesting!
We're currently use pgvectorscale. Some questions:
- Will pg_vectorsearch eventually also support vectors bigger than 1968 dimensions? E.g. VoyageAI can create embeddings with 2048 dimensions (but we don't actually need that at the moment, only 1024).
- Why did you choose C this time and not Rust, as you did with pgvectorscale?
- Why did you not just extend pgvectorscale with another index type instead of creating a whole new extensions?
Shouldn't you lead with your benchmarks if you're fast? qps and precision/recall, please.
benchmarks are in the blog post and the benchmarking suite is also open sourced alongside it.
There are zero hits for 'blog' on the README and zero hits for the file name 'benchmark'. I suggest improving its discoverability.
It’s there. Titled “Announcing pg_vectorsearch: Scalable Open-Source Vector Search in PostgreSQL”. In paragraph: “ The result: an index that is significantly faster”
There's a link in the README, but it is not named blog.
Here's the link to the numbers for your convenience:
https://www.tigerdata.com/blog/announcing-pg_vectorsearch-sc...
https://news.ycombinator.com/item?id=50086249