Support index based on DiskANN

[sushrut141]

Hey,

I've been reading about the DiskANN vector search index and evaluating the feasibility of implementing it here.
The DiskANN paper claims faster convergence of queries compared to HNSW, faster index creation time and better recall.

I wanted to explore adding support for DiskANN based vector index in pgvector.
My plan is to fork this repo and reuse the page structure of HNSW vectors to implement DiskANN.
Post that we can evaluate / compare performance against HNSW and see if it is worth merging here.

Would you be open to this contribution?
If so, any pointers / design constraints you would like to highlight?

Thanks

[jkatz]

@sushrut141 Sounds like a fun project!

For my 2¢, my feelings are relatively unchanged from #285 (comment) (though some of those items are now added to pgvector!). I've actually done some benchmarking on HNSW + DiskANN that I hope to share in the coming weeks, but for my high-level take, on key ANN search performance metrics, from the perspective of PostgreSQL and some specific implementations, I've seen limited benefit of DiskANN over HNSW, and I think some tweaks to pgvector HNSW could close that gap. However, perhaps this can be overcome with a different implementation. I'll write more about that in the near future.

[sushrut141]

Thanks @jkatz , I'll work on building a prototype using DiskANN in pgvector.
Once it's ready we can perhaps run it through the benchmarks you used in your article .

[SunnyBo0302]

@sushrut141

Hi! I’m also really interested in the comparison between DiskANN and pgvector

From what I understand in the paper:
1. DiskANN uses an in-memory graph structure with PQ-compressed data.
2. It introduces a new graph construction algorithm called Vamana.
3. A custom disk layer structure is also applied for efficient access.

Are you planning to implement all of these components, or just a subset?

Also, I noticed that pgvectorscale has implemented DiskANN support, but it’s unclear which parts of the original design they adopted. Would love to hear your thoughts!

[minleejae]

Hi @sushrut141 and @jkatz,

Thanks for the great discussion here — I wanted to follow up with a quick question.

From my perspective, while in-memory vector indexes (like HNSW) are often sufficient when working with small datasets or when there's ample hardware budget, in many real-world production scenarios, it can be difficult to secure machines with large memory pools due to cost constraints. In such cases, disk-based indexing like DiskANN appears to be a practical and compelling alternative.

For example, Microsoft has adopted DiskANN in production via Azure Cosmos, and as @SunnyBo0302 mentioned, TimescaleDB seems to be implementing their own version based on the original paper. It seems like there’s growing momentum around this design.

Given these developments, I’m curious if there’s any plan or interest in adding an official DiskANN implementation to pgvector itself (beyond pgvectorscale), either as a new index type or as an extension module? I think it could broaden pgvector’s applicability for users working with very large datasets on limited infrastructure.

Thanks!

[sdhull]

At the very least, it seems like it might be worth linking to pgvectorscale in the Readme "Indexing" section, as in their readme, the very first paragraph opens with "pgvectorscale complements pgvector"