DecoupleVS: Decoupled Vector Storage

• DecoupleVS is a decoupled vector storage management framework that separates full-precision vectors from auxiliary metadata, enabling independent optimization of compression and I/O access.
• It leverages tailored lossless compression, hierarchical data layouts, sparse in-memory indexing, and adaptive prefetching to reduce disk I/O wait times and update overhead.
• Empirical results on billion-scale datasets show that DecoupleVS can reduce storage space by up to 58.7% and deliver up to 2.58× higher query performance compared to traditional monolithic designs.

DecoupleVS is a decoupled vector storage management framework for disk-based approximate nearest neighbor search (ANNS) systems that stores vector payloads and auxiliary index metadata in distinct on-disk files, ordered identically by vector ID, so that each component can be optimized according to its own compressibility, access pattern, and update behavior (Ren et al., 10 Apr 2026). The framework targets the inefficiencies of monolithic designs in which full-precision vectors and graph or posting-list metadata are co-located. Its design combines tailored lossless compression, hierarchical data layouts, sparse in-memory indexing, cached compressed neighbor lists, adaptive vector prefetching, and append-only update handling. On real-world public and proprietary billion-scale datasets, it reduces storage space by up to 58.7% while maintaining high search and update performance and high search accuracy (Ren et al., 10 Apr 2026).

1. Problem setting and design rationale

DecoupleVS is motivated by three inefficiencies identified in state-of-the-art disk-based ANNS systems. First, co-location creates substantial storage overhead. The paper gives a concrete example: for a 128-D FP32 vector, the vector itself occupies 512 bytes, and storing 128 neighbors with 4-byte IDs adds another 512 bytes, resulting in 1 KiB per entry. At billion scale, this overhead is amplified further by replication for availability (Ren et al., 10 Apr 2026).

Second, co-location causes excessive reads during search. The framework analyzes graph-based traversal in DiskANN-like systems and reports that, even with I/O-compute pipelining, I/O wait time still dominates search latency in PipeANN, accounting for 52.9–72.2% of search latency. This is traced to a mismatch between what is frequently needed during traversal and what is actually stored together in page-aligned entries: neighbor lists are accessed repeatedly, while full-precision vectors are needed sparsely for final reranking (Ren et al., 10 Apr 2026).

Third, co-location causes severe write amplification during updates. If vector payloads and metadata share the same on-disk structure, even small metadata changes can force rewriting large sections of the index file to preserve consistency. DecoupleVS treats this as a structural rather than merely implementation-level problem. The paper attributes the root causes to the different semantics and compressibility of vectors and metadata, and to their different access patterns. Vectors are high-dimensional numeric arrays with byte-positional locality, whereas auxiliary index metadata are monotonically increasing integer lists amenable to Elias-Fano-style encoding (Ren et al., 10 Apr 2026).

This rationale positions DecoupleVS as a storage-management intervention rather than a new graph index. It is implemented atop graph-based indexing and is intended to preserve search quality through full-precision reranking while reducing space, traversal I/O, and update overhead.

2. Decoupled architecture and data organization

The architectural core of DecoupleVS is a decoupled storage model in which vector payloads and auxiliary index metadata are stored in distinct on-disk files, ordered identically by vector ID. In memory, the system maintains PQ-compressed vectors for fast distance approximations, compression metadata such as Huffman tables per segment and chunk headers, a sparse index over neighbor-list blocks, and a cache of hot compressed neighbor lists (Ren et al., 10 Apr 2026).

The vector store is organized hierarchically as segments, chunks, and fixed-size disk blocks. A segment is a file with fixed capacity; it is mutable while open, supports append-only writes, and is sealed when full. Compression is then applied asynchronously. Within a segment, chunks have fixed capacity, and each chunk stores metadata including first-block offset, number of blocks, boundary IDs per block, and, if delta coding is used, the base vector. Blocks are 4 KiB, the minimum I/O unit, with headers storing the number of vectors and their cumulative compressed sizes and tails storing compressed vector data (Ren et al., 10 Apr 2026).

The index store uses compressed adjacency lists arranged block-wise. A sparse in-memory index stores boundary IDs for block lookup, and this index is itself persisted to a single file for fast loading at startup. A separate mapping layer provides vector-ID-to-segment/chunk/block-offset resolution through in-memory chunk metadata. These choices reflect the paper’s claim that the decoupled layout eliminates co-location’s internal fragmentation and rewrite costs (Ren et al., 10 Apr 2026).

A useful quantitative model appears in the chunk-metadata overhead formula. If $C$ is the uncompressed chunk size, $\alpha \in (0,1]$ is the compressed-to-uncompressed size ratio, $V$ is the full-precision vector size, and the block size is 4096 bytes, then the per-chunk metadata overhead is

$\beta = \frac{V + 12}{C} + \frac{\alpha}{1024}.$

This formula expresses a recurring theme in DecoupleVS: decoupling is not only a logical separation, but also a way to make metadata costs explicit and tunable (Ren et al., 10 Apr 2026).

3. Compression methods and search processing

DecoupleVS uses different lossless compression methods for vectors and index metadata. For vectors, it combines XOR-based delta coding with Huffman coding. For each chunk, a base vector is constructed by choosing the most frequent byte at each position; each vector is then XORed with the base, and the XOR deltas are Huffman-coded. The compression is lossless, so full-precision vectors are perfectly reconstructed for reranking (Ren et al., 10 Apr 2026).

The design is justified empirically by measured byte-positional locality. The paper reports that columnar entropy is lower than global entropy by 34.3% on SIFT1M and 34.8% on DecoupleVS1M, which is presented as evidence that vector bytes are more compressible when treated positionally rather than monolithically. For auxiliary metadata, DecoupleVS sorts neighbor IDs in ascending order and applies Elias-Fano’s two-level representation, exploiting monotonicity (Ren et al., 10 Apr 2026).

The search workflow has three stages. Candidate generation operates on the index store using in-memory PQ codes, with traversal parameters including candidate list size $L$ and beam width $W = 4$. Neighbor lists are accessed via the sparse index and cache, decoded with Elias-Fano, and scored using PQ-based approximate distances. The approximation used is

$$d(x,y) \approx \sum_{m=1}^{M} \left\|x^{(m)} - c_{m,k(y,m)}\right\|^2.$$

Adaptive vector fetching then pulls full-precision vectors from the vector store. In phase 1, the system maintains a max-heap of size $K+B$ and begins prefetching when the heap is stable for $B$ consecutive expansions, using only bandwidth not already consumed by traversal I/Os. In phase 2, reranking proceeds in batches, and a benefit ratio—defined as the fraction of candidates that update the final top-$K$ heap—is monitored; if the ratio falls below a threshold such as 0.01, reranking terminates early (Ren et al., 10 Apr 2026).

The framework evaluates search quality with

$\alpha \in (0,1]$0

where $\alpha \in (0,1]$1 is the returned top-$\alpha \in (0,1]$2 set and $\alpha \in (0,1]$3 is the ground-truth top-$\alpha \in (0,1]$4. It also states the standard distance functions

$\alpha \in (0,1]$5

Ablation results on SIFT100M show the practical effect of decoupling on traversal I/O: graph I/Os drop from 54.8 for DiskANN and 58.0 for PipeANN to 9.9 per query on average, while total disk I/O time falls to 1.78 ms versus 2.52 ms and 3.23 ms, respectively. The same experiment reports graph cache-hit increases of 55.4% versus DiskANN and 91.9% versus PipeANN, with decompression overhead measured at approximately 2.4% of query latency (Ren et al., 10 Apr 2026).

4. Update path, garbage collection, and storage economics

The update path in DecoupleVS separates metadata maintenance from vector persistence. Inserts follow FreshDiskANN’s batch insertion into an in-memory Vamana index; when a threshold is reached, neighbor deltas are computed and applied to the on-disk auxiliary index per batch. Full-precision vectors are appended to the current mutable segment tail, and ID-to-location mappings are maintained in segment groups (Ren et al., 10 Apr 2026).

Deletes are buffered and then applied in batch form to neighbors’ adjacency lists to preserve graph connectivity. Vector entries are marked stale rather than rewritten in place. Space reclamation is delegated to asynchronous segment-level garbage collection, which is triggered when the garbage ratio exceeds a threshold. The system greedily selects high-garbage segments, compacts valid vectors into new segments, updates in-memory metadata to new locations, and frees the old segments (Ren et al., 10 Apr 2026).

The paper defines write amplification in the standard way:

$\alpha \in (0,1]$6

The principal claim is that decoupling reduces this factor because only compressed auxiliary metadata are rewritten during merges, whereas vector data use append-only writes plus background garbage collection. On SIFT100M under streaming updates, DecoupleVS reduces peak storage size by 33.6% relative to DiskANN. In the update breakdown, it reduces disk I/O time by 13.0% for Merge-Delete and 8.0% for Merge-Insert, while CPU time rises modestly because compression operations and reduced I/O waits increase CPU utilization (Ren et al., 10 Apr 2026).

The storage economics of metadata compression are also formalized. For a neighbor list of size $\alpha \in (0,1]$7 and maximum ID $\alpha \in (0,1]$8, the Elias-Fano worst-case bound is

$\alpha \in (0,1]$9

whereas the uncompressed list uses $V$0 bits. This bound is used not only analytically but also operationally: DecoupleVS dimensions fixed-size cache entries for compressed neighbor lists according to the worst-case Elias-Fano size, which avoids fragmentation and unpredictable allocations during cache management (Ren et al., 10 Apr 2026).

5. Empirical performance

The evaluation spans 100M-scale and billion-scale datasets, including DecoupleVS100M, SIFT100M, SPACEV100M, SIFT1B, and SPACEV1B. Experiments run on a server with dual 32-core Xeon Platinum 8336C processors, 512 GB DDR4, and a Samsung PM9A3 3.84 TB NVMe SSD, using a C++ implementation built on PipeANN with 19.1 KLoC added (Ren et al., 10 Apr 2026).

The most visible result is the space reduction relative to monolithic systems.

Dataset scale	Reduction vs DiskANN	Reduction vs SPANN
DecoupleVS100M	58.7%	76.4%
SIFT100M	47.4%	65.1%
SPACEV100M	41.9%	53.1%
SIFT1B	33.7%	—
SPACEV1B	42.6%	—

Component-level numbers clarify where these savings arise. Relative to raw vectors, vector compression achieves 46.4% on DecoupleVS100M, 23.8% on SIFT100M, and 25.2% on SPACEV100M. Relative to DiskANN’s auxiliary index representation, Elias-Fano compression yields 63.8%, 61.3%, and 45.8% savings on the same datasets. Decoupling also reclaims internal fragmentation amounting to 10.3 GiB on DecoupleVS100M and 4.4 GiB on SIFT100M (Ren et al., 10 Apr 2026).

Search performance improves as well. On 100M-scale data at approximately 80% Recall@10 on DecoupleVS100M, DecoupleVS delivers 2.58× higher QPS than DiskANN and 2.18× higher QPS than PipeANN. In latency, it reports lower P99 latency than SPANN and DiskANN and latency comparable to PipeANN; on DecoupleVS100M at 80% recall, P99 latency is reduced by 49.0% versus DiskANN and 50.0% versus PipeANN (Ren et al., 10 Apr 2026).

Under concurrent search and updates on SIFT100M, with 50% of the data replaced in 10 iterations and each iteration containing 5% delete plus 5% insert, DecoupleVS shows an average throughput gain of 1.88× over DiskANN, reduces P50 and P99 latency by up to 51.0% and 49.4%, maintains comparable accuracy with an average recall drop of 0.13%, increases memory usage by 1.1% on average because of compression metadata, and reduces peak storage size by 33.6% (Ren et al., 10 Apr 2026).

These results support the paper’s central design claim: decoupling enables simultaneous specialization of compression, layout, caching, and update paths, rather than forcing a single storage abstraction to serve incompatible workloads.

6. Limitations, operating regimes, and practical deployment

DecoupleVS is not presented as universally dominant. The paper explicitly identifies regimes in which decoupling may help less. Very small datasets or fully in-memory indexes may not benefit because co-location can exploit sequential locality and direct addressing, while decoupling introduces variable-size management and metadata overhead. At the lowest-accuracy settings, PipeANN slightly outperforms DecoupleVS at $V$1 on 100M-scale workloads because DecoupleVS still performs some vector I/Os; the benefit of decoupling grows as $V$2 increases (Ren et al., 10 Apr 2026).

The compression behavior is also workload-dependent. On 8-bit quantized datasets such as SIFT100M and SPACEV100M, delta coding provides no improvement beyond entropy coding, although the framework still achieves notable vector compression. Sequential locality is weakened by decoupling, so runtime efficiency depends on the block-and-chunk layout, hot-list caching, and adaptive prefetching. The paper therefore treats cache size and the benefit-ratio threshold as deployment-critical parameters rather than incidental tunables (Ren et al., 10 Apr 2026).

The recommended default configuration reflects this engineering orientation. For 100M-scale deployments, the paper uses graph degree $V$3, build candidate size $V$4, search candidate sizes $V$5, beam width $V$6, chunk size $V$7 MiB, segment size 512 MiB, cache capacity near 1% of the dataset, reranking batch size $V$8, and benefit ratio 0.01. For billion-scale datasets, it uses $V$9, $\beta = \frac{V + 12}{C} + \frac{\alpha}{1024}.$0, and cache capacity near 0.1% of the dataset, with the remaining defaults unchanged (Ren et al., 10 Apr 2026).

A plausible implication is that DecoupleVS is best understood as a systems framework for storage specialization under disk-bound, billion-scale ANNS conditions rather than as a replacement for index design itself. The graph structure remains central, but the co-location assumption is treated as an avoidable systems constraint. Within that framing, the framework’s contribution is to show that vector payloads and auxiliary metadata can be separated without sacrificing search accuracy, and that the separation creates optimization opportunities that monolithic layouts suppress (Ren et al., 10 Apr 2026).