AiSAQ holds query-time RAM at 10 MB on a billion-vector index by moving PQ codes to SSD

A DiskANN query scores candidates against product-quantized vectors held in memory, then reads full-precision vectors off storage to re-rank the nodes on the search path ^[4]. The SSD tier exists in the first place because DRAM is too expensive to hold a billion-scale dataset ^[14]. The memory half is what grows: PQ codes for all nodes stay resident, so the footprint tracks the corpus ^[1]. An operator who wants it smaller raises the compression ratio, and the paper is blunt about that knob, since more compression cuts memory usage and recall together ^[5].

AiSAQ moves the PQ codes onto storage as well. Query search then uses about 10 MB of DRAM at any dataset size, including the billion-vector SIFT1B, with the graph topology and the recall of the original DiskANN unchanged ^[2][3]. Candidate scoring now reads from the device, and the authors' answer to that is where the bytes sit on it; they report millisecond-order latency at 95 percent 1-recall@1 ^[6].

For that 10 MB to transfer to your service, your query pattern has to look like the one they measured. The abstract and introduction report memory, recall and latency. They do not report queries per second under concurrent load, or per-query read volume ^[16]. They ran a search process on local storage; a hundred tenants sharing one device queue is a different test.

The flat footprint does turn the tenant question into a scheduling one. If each tenant's search ran as its own resident process, 100 of them would come to about 1 GB of query-time memory ^[15]. The paper's own path is different: index load time before query search is small enough that one service can switch corpora per user request ^[7], in millisecond order between billion-scale datasets ^[9], and sub-millisecond when two datasets share their PQ centroid vectors ^[8]. The paper also argues DiskANN is unsuited to switching for the same reason it is unsuited to scale, because loading all PQ vectors into DRAM takes too long ^[12].

This matters for adoption because DiskANN is the baseline for the NeurIPS Big-ANN competition track and is used in Weaviate and Zilliz, per the paper ^[10]. The authors describe their contribution as index data placement, applicable to all graph-based ANNS algorithms ^[11]. The change is where bytes live, and in my view a vector store can take that on behind an index format it already ships. The paper lists LM-DiskANN as concurrent work ^[13].