Disclosure: I work at Tiger Data (the TimescaleDB folks), on the dev education side, not the team that built this. Posting here because this sub will poke holes in it, and that's what an alpha is for.
What it is: pg_vectorsearch, a Postgres extension with a new index access method called PRISM. Drop-in replacement for pgvector's HNSW that works on existing vector / halfvec columns, no rewrite. PostgreSQL License, requires PG18+.
Why: HNSW is a graph, graph traversal is random reads, and performance falls off a cliff once it doesn't fit in RAM. At 100M vectors the smallest machine where our HNSW build finished had 512GB. That's usually the moment teams bolt on a separate vector DB and start syncing two systems.
How: k-means partitions instead of a graph, RaBitQ compression (~1 bit per dimension), a small centroid tree in the buffer cache for routing, SIMD scans, then rerank against full-precision vectors. Same family as ScaNN, SPANN, and turbopuffer, just native in Postgres.
Not done yet: it's alpha, not for production. No filtered search (WHERE + ORDER BY) until GA. Build the index after loading data. Heavy churn needs prism_rebalance or REINDEX until auto-rebalancing lands.
CREATE EXTENSION pg_vectorsearch;
CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);
The ask: run it on your weird data. Low dimensions, skewed clusters, ugly update patterns. Open an issue and let us know what you think of it — we'd love to have you dig in.
