---
title: 'VDTuner: Auto Tuning for Vector Databases'
url: https://www.emergentmind.com/topics/vdtuner
type: topic
---

# VDTuner: Auto Tuning for Vector Databases

VDTuner is a learning-based automatic performance tuning framework for vector data management systems (VDMSs) that leverages multi-objective Bayesian optimization to automatically choose index type, index parameters, and system parameters while balancing search speed and recall. It was introduced to address the fact that modern VDMSs expose heterogeneous, index-dependent parameter spaces and that their performance is dominated by workload-specific trade-offs rather than by fixed vendor defaults. In the original formulation, VDTuner operates without prior domain knowledge, models the tuning problem as expensive black-box optimization, and returns either a Pareto front or a configuration selected under explicit user preferences such as recall constraints or cost-awareness [2404.10413].

## 1. Problem domain and motivation

VDMSs are databases specialized for storing high-dimensional vectors and answering similarity search queries such as top-\(K\) nearest neighbors under a distance metric. The original VDTuner study places them in the operational context of retrieval-augmented generation, large-scale recommendation, search, and other embedding-centric systems, and emphasizes that systems such as Milvus expose multiple index types together with index-specific and system-level knobs. The core difficulty is not merely parameter optimization within a fixed algorithm, but joint selection of index type, build-time parameters, query-time parameters, and global system parameters in a mixed, conditional configuration space [2404.10413].

The motivating obstacles are explicitly structured around three properties. First, the parameter space is high-dimensional, mixed-type, and hierarchical: if one index type is chosen, only a subset of parameters is semantically active. Second, speed and recall are inherently conflicting objectives, so scalar single-objective tuning can over-optimize one metric at the expense of the other. Third, index-type selection must be performed under a limited evaluation budget, even though different index families can dominate on different datasets and early observations are noisy. VDTuner is therefore positioned not as a simple hyperparameter search routine, but as a dedicated auto-tuner for VDMSs whose search space violates the fixed-parameter assumptions of many existing DBMS tuners [2404.10413].

A recurring misconception is that VDMS tuning is equivalent to tuning one ANN structure in isolation. The original work rejects that view by treating the index type itself as part of the optimization problem. Later work retained that characterization: in a FastPGT study on proximity-graph construction, VDTuner is described as the state-of-the-art learning-based tuning method for vector data systems, while in a later LLM-guided optimizer study it is described as a prior system aimed at automated tuning for vector databases, especially for single-stage vector search [2602.11573].

## 2. Optimization formulation

The base optimization problem in VDTuner uses a decision vector \(\mathbf{x} \in \mathcal{X} \subset \mathbb{R}^d\) that encodes the index type, the parameters for all candidate index types, and system parameters. The two primary objectives are search speed, measured as QPS, and recall, measured against ground-truth neighbors. In unconstrained mode, the objective is to recover a Pareto front over these two metrics; in constrained mode, the objective becomes maximizing search speed subject to \(f^{rec}(\mathbf{x}) \ge \text{rlim}\), where \(\text{rlim}\) is a user-provided recall threshold [2404.10413].

The surrogate model is a Gaussian Process with a Matérn \(5/2\) kernel. VDTuner uses a multi-output GP by modeling each objective separately, which yields one GP for speed and one GP for recall. A central device in that formulation is the polling surrogate based on Normalized Performance Improvement (NPI). For a configuration \(\mathbf{x}_i\) belonging to index type \(t\), with observed performance \((y_i^{spd}, y_i^{rec})\), the normalized target is
\[
(\hat{y}^{spd}_i, \hat{y}^{rec}_i) =
\left(
\frac{y_i^{spd}}{\overline{y}_t^{spd}},
\frac{y_i^{rec}}{\overline{y}_t^{rec}}
\right),
\]
where \((\overline{y}_t^{spd}, \overline{y}_t^{rec})\) is the “most balanced” non-dominated point for that index type. This normalization removes gross scale differences among index families and stabilizes cross-index modeling [2404.10413].

For unconstrained tuning, the acquisition function is Expected Hypervolume Improvement (EHVI):
\[
\alpha_{EHVI}(\mathcal{X}', \mathbf{r}, \mathcal{Y})
=
\mathbb{E}
\left[
HV(\mathbf{r}, \mathcal{Y} \cup \{\mathbf{f}(\mathcal{X}')\}) - HV(\mathbf{r}, \mathcal{Y})
\right].
\]
Here \(\mathcal{Y}\) denotes the current set of non-dominated observations and \(\mathbf{r}\) is a reference point. For recall-constrained operation, VDTuner switches to constrained Expected Improvement (CEI),
\[
\alpha_{CEI}(\mathcal{X}_{cand}, rlim)
=
\alpha_{EI}(\mathcal{X}_{cand}) \cdot Pr(f^{rec}(\mathcal{X}_{cand}) > rlim),
\]
which explicitly multiplies speed improvement by the probability of satisfying the recall floor. This separation between unconstrained Pareto optimization and recall-constrained optimization is one of the framework’s distinguishing methodological features [2404.10413].

The same paper also defines a cost-aware variant. Instead of optimizing raw QPS, it replaces the speed objective with cost effectiveness,
\[
\text{Cost-Eff.} = \frac{\text{Search Speed}}{\eta \cdot \text{Memory Usage}},
\]
with \(\eta=1\) in the reported experiment. This formulation preserves the BO machinery while altering the utility function, allowing VDTuner to target QPS per unit memory rather than QPS alone [2404.10413].

## 3. Architecture and tuning workflow

VDTuner is organized as an iterative control loop over a live VDMS. Its main components are a unified configuration space, a performance evaluator that applies configurations and replays workloads, a holistic multi-objective BO engine, and a result extractor that maintains the non-dominated set. In the experimental implementation, each evaluated configuration may require index rebuild and workload replay, and failed runs such as crashes or executions exceeding 15 minutes are assigned the worst observed values so that the optimizer avoids re-entering unstable regions [2404.10413].

Initialization is index-aware. For every index type \(t\), VDTuner evaluates the default configuration, records the resulting speed and recall in a dataset \(\mathcal{D}_t\), and begins with one datapoint per type. The main loop then alternates among four stages: budget allocation across remaining index types, surrogate update using NPI-normalized data, acquisition-based proposal for the currently polled index type, and empirical evaluation with subsequent update of \(\mathcal{D}_t\) and the global Pareto set. The search region \(\mathcal{X}'\) at each iteration fixes the current index type and freezes irrelevant parameters to defaults, so the optimizer only varies parameters meaningful for that type [2404.10413].

Two mechanisms are specific to VDTuner’s handling of multiple index families. The first is the polling surrogate already described, which enables a single holistic GP to learn across types. The second is the successive abandon budget allocation strategy. VDTuner computes a score for each remaining index type based on hypervolume contribution and abandons index types that are consistently worst in a sliding window. The next type to evaluate is then selected in a round-robin order over the shrinking set of remaining types. This prevents uniform budget waste on poor-performing index classes while delaying abandonment until the ranking has stabilized [2404.10413].

The original study reports that BO overhead is small relative to workload replay. On GloVe, for 200 iterations, VDTuner spent 438 s in configuration recommendation and 30,034 s in workload replay, for a total of 30,472 s, with recommendation accounting for 1.44% of the total. This matters because VDTuner’s claimed efficiency does not come from cheap surrogate updates but from choosing configurations that avoid many unproductive or pathological evaluations [2404.10413].

## 4. Configuration space and supported parameters

In the Milvus 2.3.1 evaluation, VDTuner tunes 16 parameters in total: one categorical index type, eight index parameters, and seven system parameters. The supported index types are FLAT, IVF_FLAT, IVF_SQ8, IVF_PQ, HNSW, SCANN, and AUTOINDEX. Their exposed parameter sets are heterogeneous: FLAT and AUTOINDEX have no user-visible index parameters; IVF_FLAT and IVF_SQ8 use `nlist` and `nprobe`; IVF_PQ uses `nlist`, `m`, `nbits`, and `nprobe`; HNSW uses `M`, `efConstruction`, and `ef`; and SCANN uses `nlist`, `nprobe`, and `reorder_k` [2404.10413].

The system-parameter side includes Milvus configuration options such as `segment_maxSize`, `segment_sealProportion`, and `gracefulTime`, together with other parameters exposed in the configuration documentation. A salient aspect of the design is that shared parameters, such as `nlist` and `nprobe` across IVF-based indexes, appear once in the holistic representation. This allows the GP to exploit cross-index correlations on overlapping dimensions, while type-specific inactive parameters are fixed to defaults during acquisition for a given index type [2404.10413].

This structure is neither a flat tabular HPO space nor a set of completely separate per-index tuning problems. The paper explicitly contrasts VDTuner with a hypothetical strategy that tunes each index type independently and then selects the best one. In the reported scenarios, both approaches eventually identified the same best index type and near-identical parameter values, but the holistic model was more efficient because it avoided redundant initialization and shared information on global parameters and overlapping index knobs [2404.10413].

A later reinterpretation narrows the same design to proximity-graph indexes. In the FastPGT study, VDTuner is characterized as tuning graph construction and search parameters such as HNSW \((M, efc, ef)\) and RNG-family parameters such as \((L, M, \alpha, ef)\), with the same GP-plus-EHVI recommendation principle. That paper uses VDTuner as both a baseline and the recommendation model that FastPGT extends to batched recommendation [2602.11573].

## 5. Empirical performance

The original evaluation was conducted on Milvus 2.3.1 using an Intel Xeon Gold 5220 at 2.10GHz with 72 logical cores, 125 GB RAM, CentOS 7.9, and Linux 5.5. Workloads were generated via vector-db-benchmark. The main datasets were GloVe with 1,183,514 vectors of dimension 100, Keyword-match with 1,000,000 vectors of dimension 100, and Geo-radius with 100,000 vectors of dimension 2048. Queries retrieved top-100 neighbors under 10 concurrent search requests, and recall was computed against exact ground truth [2404.10413].

Against the Milvus default configuration, VDTuner reported improvements on all three datasets. On GloVe it achieved +10.46% in speed and +17.16% in recall. On Keyword-match it achieved +11.17% in speed and +62.61% in recall. On Geo-radius it achieved +14.12% in speed and +186.38% in recall. These numbers are central to the original positioning of VDTuner: the framework was not presented as a marginal optimizer, but as a mechanism for recovering substantial performance left unused by default settings [2404.10413].

The baseline comparison included Random using Latin Hypercube Sampling, OpenTuner, OtterTune, and qEHVI. The paper states that VDTuner dominated all baselines on speed across practically all recall sacrifice levels, with qEHVI usually being the strongest competing baseline. On Keyword-match, the reported speed advantage over the best baseline for increasingly strict recall sacrifice levels was 11.15%, 10.35%, 4.53%, 12.19%, 18.84%, 33.32%, and 59.54%. On GloVe, for recall sacrifices 0.1, 0.075, 0.05, 0.025, and 0.01, VDTuner required only 92%, 64%, 50%, 69%, and 32% of the sampling count used by the best baseline to reach comparable quality, with tuning-time reductions of 67%, 47%, 38%, 49%, and 28%, respectively. The paper summarizes the overall gain as up to 3.57 times faster in terms of tuning time [2404.10413].

Ablation studies attribute the observed gains to three mechanisms. Successive abandon yielded up to 34% speed improvement over a pure round-robin budget allocation. The polling surrogate yielded up to 26% speed improvement over a native GP without per-type normalization. The holistic model outperformed separate per-index tuning in efficiency while converging to very similar final parameter settings. The same evaluation also reports scalability to a larger deep-image dataset, where VDTuner dominated qEHVI and achieved target performance 8.1 times faster in tuning time, and adaptability to changing user preferences through constrained BO and bootstrapping from prior runs [2404.10413].

The cost-aware variant provides a distinct empirical picture. On Geo-radius, optimizing Cost-Eff rather than QPS directly yielded up to 13% higher cost effectiveness, but up to 5% lower QPS. Memory usage shifted from 5.19 ± 2.44 GiB under QPS tuning to 3.89 ± 1.75 GiB under Cost-Eff tuning. The paper’s SHAP analysis identified `segment_maxSize` as the most influential parameter for memory and `index_type` as the most influential parameter for speed [2404.10413].

## 6. Subsequent developments, limitations, and reinterpretations

The original VDTuner paper explicitly identifies several limitations. Tuning is offline rather than online; every configuration evaluation can require minutes because it includes index build or rebuild plus workload replay; the framework is tuned per dataset and workload rather than for multi-tenant operation; and the evaluation concentrates on a 16-dimensional space rather than on much larger parameterizations. The paper also notes that severe noise and non-stationarity are not treated explicitly, and that parameter ranges and some normalization choices remain integrator-defined [2404.10413].

Later work sharpened these limitations in two different directions. In the FastPGT study on proximity graphs, VDTuner is treated as the main baseline and as the underlying recommendation model, but the dominant critique is systems-level rather than statistical: parameter estimation dominates total tuning time because each recommended configuration requires building and evaluating a full proximity graph. On Sift, that study reports VDTuner’s recommendation time as approximately 438 s and its parameter estimation time as approximately 32,568 s, or 98.67% of the total. FastPGT then reports up to 2.37x speedup over VDTuner without compromising tuning quality by recommending multiple parameters at once and building multiple graphs simultaneously with shared computations [2602.11573].

A different critique appears in the LLM-guided ANN index optimization study for human-object interaction retrieval. There, VDTuner is described as extending OtterTune’s approach to multi-objective Bayesian optimization across seven index types in Milvus, but operating on single-stage vector search without cross-stage coupling. Under the SIEVE objective, which sets score to QPS only when quality exceeds a hard threshold and to zero otherwise, the authors report that VDTuner performs less reliably when performance changes discontinuously at a quality threshold rather than gradually. On HICO-DET within Intel VDMS, the LLM agent achieved a Score of 300.3 versus 223.8 for VDTuner, corresponding to a +34.2% improvement under SIEVE; on GLDv2, however, VDTuner and the LLM agent were within about 1% of each other, with VDTuner slightly ahead; and on SIFT1M the gap was approximately 3% in favor of the LLM agent. This suggests that VDTuner remains competitive in single-stage or near-independent parameter spaces, while its assumptions become less reliable in tightly coupled, thresholded, multi-stage retrieval pipelines [2606.05489].

Taken together, these later studies do not negate VDTuner’s original contribution. Rather, they delimit its operating regime. Within the problem class for which it was designed—offline tuning of VDMS index and system parameters under speed-recall trade-offs in a hierarchical but largely single-stage search setting—it established a strong MOBO baseline with explicit handling of index-type heterogeneity, recall constraints, and cost-aware objectives. Subsequent research has mainly extended two aspects that VDTuner left only partially addressed: the systems cost of evaluation and the modeling of strongly coupled or discontinuous objectives [2602.11573].

Source: https://www.emergentmind.com/topics/vdtuner