Papers
Topics
Authors
Recent
Search
2000 character limit reached

LatentTune: Efficient Tuning of High Dimensional Database Parameters via Latent Representation Learning

Published 4 Feb 2026 in cs.DB | (2602.04190v1)

Abstract: As data volumes continue to grow, optimizing database performance has become increasingly critical, making the implementation of effective tuning methods essential. Among various approaches, database parameter tuning has proven to be a highly effective means of enhancing performance. Recent studies have shown that machine learning techniques can successfully optimize database parameters, leading to significant performance improvements. However, existing methods still face several limitations. First, they require substantial time to generate large training datasets. Second, to cope with the challenges of highdimensional optimization, they typically optimize only a subset of parameters rather than the full configuration space. Third, they often rely on information from similar workloads instead of directly leveraging information from the target workload. To address these limitations, we propose LatentTune, a novel approach that differs fundamentally from traditional methods. To reduce the time required for data generation, LatentTune incorporates a data augmentation strategy. Furthermore, it constructs a latent space that compresses information from all database parameters, enabling the optimization of the full configuration space. In addition, LatentTune integrates external metric information into the latent space, allowing for precise tuning tailored to the actual target workload. Experimental results demonstrate that LatentTune outperforms baseline models across four workloads on MySQL and RocksDB, achieving up to 1332% improvement for RocksDB and 11.82% throughput gain with 46.01% latency reduction for MySQL.

Summary

  • The paper introduces LatentTune , a framework that efficiently tunes high-dimensional database parameters by leveraging latent representation learning and augmentation, achieving significant performance improvements over traditional methods on multiple database systems.
  • LatentTune manages three key contributions: skipping costly benchmark runs with Latin Hypercube Sampling and TabNet prediction, encoding parameter–performance dependency in a latent space through concatenated inputs, and optimizing via Bayesian optimization (Typical: 1332% improvement over baseline in some RocksDB workloads).
  • The results validate the LatentTune framework's ability to deliver superior performance across diverse database workloads by ensuring full-space optimization and convergent accurate prediction of configuration
  • recent papers Latent Representation Learning in Database Optimization

Motivation and problem statement

ML-based database parameter tuning systems such as OtterTune, CDBTune, and RGPE have demonstrated that learned optimizers can outperform manual DBA-driven configuration, but the authors identify three structural limitations in this line of work. First, training data generation is expensive: each (configuration, metric) pair requires a benchmark run, and with a 300-second benchmark per configuration, assembling 1,000 MySQL samples consumes substantial wall-clock time. Second, to cope with high-dimensional search spaces, BO-based methods prune the space via feature-selection algorithms such as SHAP or LASSO and tune only the top-kk knobs. The paper shows this pruning is fragile: for RocksDB workloads R90W10 and R50W50, SHAP and LASSO agree on only three to five of their top-10 parameters, and the resulting performance differences between top-5 and top-10 selections are large. Third, existing pipelines transfer knowledge from the most similar stored workload via distance metrics over internal metrics; because internal metrics capture low-level system behavior rather than high-level workload structure (query patterns, transaction sizes, read/write ratios), inaccurate workload mapping can yield suboptimal configurations.

The LatentTune framework

LatentTune addresses all three limitations through three coupled modules. Sample augmentation expands a small measured dataset D\mathcal{D} of configuration–metric pairs into an augmented set D^\hat{\mathcal{D}}: Latin Hypercube Sampling generates new configurations uniformly across the parameter space, and a TabNet model predicts their metric values, avoiding additional benchmarking. LHS is chosen over simple random and Gaussian sampling for its balanced coverage of wide-range, high-dimensional spaces. Latent space generation trains an autoencoder on inputs formed by concatenating each configuration with its external performance metrics (IRd+eI \in \mathbb{R}^{d+e}), minimizing reconstruction loss. Concatenation is deliberate: since raw configuration values carry little semantic structure, injecting metric information lets the latent space encode parameter–performance dependencies and implicitly represent target-workload characteristics — removing the need for similarity-based workload mapping entirely. Latent space optimization runs Bayesian optimization with a Gaussian Process surrogate and Expected Improvement acquisition over the low-dimensional latent vectors z[0,1]lz \in [0,1]^l (32 dimensions for MySQL, 16 for RocksDB). Because benchmarking inside the BO loop would be prohibitively slow, the objective function is itself replaced by a second, independently trained TabNet predictor mapping latent vectors to metrics, combined via scalar score functions (throughput/latency ratio for MySQL; a weighted combination of TIME, RATE, WAF, and SAF for RocksDB).

Experimental results

The evaluation covers four YCSB workloads (A, B, E, F) on MySQL v5.7.37 and four read/write mixes (R90W10, R50W50, R10W90, UPDATE) on RocksDB v6.25.0, against OtterTune, CDBTune, and RGPE baselines, each run five times with different seeds. LatentTune achieves the best results across all workloads, with headline figures of up to 1332% improvement on RocksDB (composite log-score of 9.19 over default) and 11.82% throughput gain with 46.01% latency reduction on MySQL. On the read-heavy YCSB B workload, throughput gains are marginal for all methods — lightweight operations place minimal stress on the system — but latency still improves markedly through concurrency- and I/O-related parameters, which the authors attribute to full-space optimization capturing effects that top-kk selection misses.

Supporting analyses reinforce the design choices. TabNet's multi-label prediction accuracy justifies its use in both augmentation and objective-function roles: on RocksDB it reaches R2R^2 values of roughly 0.72–0.99 across TIME/RATE/WAF/SAF, whereas Random Forest and XGBoost, competitive on MySQL's two-label task, degrade inconsistently on RocksDB's four-label task. In the BO-stage prediction comparison, TabNet dominates decisively (e.g., R2=0.85R^2 = 0.85/$0.79$ for YCSB E throughput/latency versus 0.45/0.42 for the next-best CatBoost). Contour-density analysis shows optimized and non-optimized latent vectors forming clearly separated clusters, and decoded optimized configurations concentrate in high-throughput, low-latency regions with lower variance and no outliers under IQR analysis.

Ablation findings

The ablation study isolates the contribution of each module and reveals a strong interaction effect. BO directly in the full-dimensional space (no augmentation, no latent space generation) performs worse than the default configuration due to the curse of dimensionality degrading GP surrogate learning. Augmentation alone yields only slight gains for the same reason. Latent space generation alone produces the poorest results among combinations: without augmented data, the autoencoder is under-trained and fails to compress meaningful information, which in turn corrupts the TabNet objective model. Only the combination of both modules delivers consistent improvements, indicating the two components are jointly necessary rather than independently sufficient.

Limitations and open questions

Several caveats bear directly on the reported results. The augmentation pipeline depends on the fidelity of predicted metrics rather than measured ones; while TabNet's R2R^2 scores are high, prediction error in the BO objective could bias the search toward regions where the predictor is systematically wrong, and the paper does not quantify end-to-end sensitivity to this error. The data-scaling analysis finds reconstruction loss and tuning performance peak at 5,000 total samples and degrade beyond ~5,500, attributed to the limited information content of the data and the dilution of original measurements — implying the approach has a dataset-size ceiling whose position may vary across DBMSs and hardware. Tuning time (57–60 minutes on MySQL) exceeds OtterTune (~48–50 minutes) because of autoencoder training overhead, so the method trades preprocessing time for convergence quality. Experiments are confined to two single-node DBMSs with fixed hardware and static workloads; distributed systems, dynamic environments, and real-time retuning remain unaddressed, and the score functions for multi-metric objectives require manually chosen weights whose sensitivity is not analyzed.

Conclusion

LatentTune reformulates database knob tuning as optimization in a learned latent space that jointly encodes the full configuration vector and target-workload performance information, supported by LHS-based sampling and TabNet-based metric prediction to sidestep costly benchmarking during both data generation and BO evaluation. The empirical evidence — consistent superiority over OtterTune, CDBTune, and RGPE across eight workloads on two DBMSs, plus ablations showing the necessity of combining augmentation with latent compression — supports the claim that full-parameter, workload-specific optimization is feasible without top-D\mathcal{D}0 selection or similarity-based workload mapping. The main open questions are robustness to predictor error, generalization beyond single-node settings, and adaptation to dynamically shifting workloads.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.