DISKANN (Disk-based ANN)

DISKANN is a disk-optimized vector index designed for very large collections—the kind where keeping the full index in memory would be too expensive.

In VBase, DISKANN is useful when:

• Your collection is too big to keep an index fully in RAM.
• You can store index data on fast SSD/NVMe.
• You’re okay trading a bit more latency (disk reads) for much larger scale.

How DISKANN works

DISKANN combines two ideas:

• Vamana graph (on disk): a graph where each vector is a node connected to nearby nodes. The graph is stored on disk so it can scale to very large datasets.
• Product Quantization (PQ) codes (in memory): a compressed representation of vectors stored in RAM, used to quickly estimate distances before doing more expensive exact reads.

What happens during a search

1. Start from an entry point in the graph.
2. Explore neighbors using the in-memory PQ codes to cheaply approximate distances.
3. Select promising candidates and read their original vectors from disk for more accurate scoring.
4. Repeat until you have enough nearest neighbors.

The key idea: most work stays in memory, and only a smaller set of candidates requires disk reads.

When to choose DISKANN

Use DISKANN when your priority is scalability:

• ✅ Massive datasets where index-in-RAM would be cost prohibitive
• ✅ High recall is still desired, but you want better cost-efficiency than purely in-memory indexes
• ✅ Your storage is fast enough (NVMe strongly recommended)

Avoid DISKANN when:

• ❌ Your dataset fits easily in memory (an in-memory index may be faster)
• ❌ Storage is slow or noisy (HDD / slow network disks will hurt)

Requirements

• Fast local storage for the index data (NVMe SSD recommended).
• DISKANN must be enabled on the underlying cluster (it is disabled by default in Milvus).

If you self-host the underlying Milvus deployment, enable disk index support in milvus.yaml:

queryNode:
  enableDisk: true

If you’re using a managed VBase deployment, DISKANN availability depends on your cluster configuration.

Create a DISKANN index in VBase

The exact VBase method names may differ depending on your SDK version, but the shape of the request is the same:

• Index type: DISKANN
• Metric: typically COSINE, IP, or L2 (match your embedding model)

Example (conceptual):

# Assume you already created a collection with a vector field (e.g. "embedding").
 
vbase.create_index(
    collection_name="my_collection",
    field_name="embedding",
    index_type="DISKANN",
    metric_type="COSINE",
)

Load before searching

Like other ANN indexes, DISKANN must be loaded before it can serve queries.

vbase.load_collection("my_collection")

If the collection (or its index) is not loaded, searches can fail or be forced into slow paths.

Tuning DISKANN

DISKANN tuning is split into two categories:

1) Build-time parameters (cluster config)

These are configured at the cluster level (for example in milvus.yaml). They affect index build time, memory usage, and recall.

• MaxDegree: max edges per node in the Vamana graph.
  • Higher = better recall, higher memory + build cost.
• SearchListSize: how wide the builder explores when connecting nodes.
  • Higher = higher-quality graph, slower index build.
• PQCodeBudgetGBRatio: how much RAM to spend on PQ codes relative to raw vector size.
  • Higher = better approximations (better recall), more memory.
• SearchCacheBudgetGBRatio: memory allocated for caching frequently accessed disk data.
  • Higher = fewer disk reads, more memory.

Example:

# milvus.yaml
common:
  DiskIndex:
    MaxDegree: 56
    SearchListSize: 100
    PQCodeBudgetGBRatio: 0.125
    SearchCacheBudgetGBRatio: 0.10
    BeamWidthRatio: 4

2) Query-time parameter (search params)

• search_list: candidate pool size while traversing the graph.
  • Higher = higher recall, higher latency.

Example (conceptual):

results = vbase.search(
    collection_name="my_collection",
    data=[query_vector],
    top_k=10,
    search_params={
        "search_list": 100,
    },
)

Practical defaults

If you’re not sure where to start:

• Keep MaxDegree in the 10–100 range.
• Set SearchListSize >= MaxDegree.
• Start with BeamWidthRatio = 4.
• Start with search_list around top_k to 10× top_k, then tune.

Summary

• DISKANN is a great fit for large-scale vector search.
• It keeps the graph on disk and uses in-memory PQ for fast approximate scoring.
• You’ll get the best results with NVMe storage and careful tuning of build + query parameters.