Posted by jascha_eng 9 hours ago
- 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.
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) <-> ) < $1
AND b.id != a.id
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.
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.
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.
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:
https://www.linkedin.com/pulse/inside-pgvectorsearch-archite...
Edit: post filtering only
I don't understand how people are efficiently implementing tenant/user/permission scopes with these indexes.
But how are people doing recency biasing with vector databases?
All of our approaches are either expensive or super hacky.
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.
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.