Paper deep dive
ScaleSense: Cost-Intelligent Scaling Framework via Learned Resource Estimation in Alibaba AnalyticDB
Yifan Wu, Yuhan Li, Zhenhua Wang, Ke Chen, Lidan Shou, Zonghao Chen, Liang Lin, Huan Li, Gang Chen
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 88%
Last extracted: 8/11/2026, 4:32:58 AM
Summary
The paper introduces ScaleSense, a cost-intelligent, query-level resource scaling framework for Alibaba AnalyticDB. It addresses the 'provisioning trap' of over-provisioning in cloud-native serverless data warehouses by using a multi-faceted query encoder and a quantile-based resource predictor to estimate physical footprints (CPU, memory, disk, network) and latency. An auto-scaling controller then selects optimal Compute Unit (CU) configurations based on user-defined performance or cost optimization policies, achieving significant cost reductions and improved accuracy over baselines.
Entities (10)
Relation Signals (9)
ScaleSense → deployedon → Alibaba AnalyticDB
confidence 95% · ScaleSense: Cost-Intelligent Scaling Framework via Learned Resource Estimation in Alibaba AnalyticDB
ScaleSense → optimizes → Compute Unit (CU)
confidence 92% · determining the optimal resource allocation... AnalyticDB abstracts computational capacity into Compute Units (CUs)
ScaleSense → consistsof → Multi-faceted Query Encoder
confidence 90% · Specifically, it features a multi-faceted query encoder
ScaleSense → consistsof → Quantile Resource Predictor
confidence 90% · Crucially, a quantile-based resource predictor estimates multi-dimensional physical footprints
ScaleSense → consistsof → Auto-Scaling Controller
confidence 90% · An auto-scaling controller then navigates the performance-cost Pareto frontier
ScaleSense → evaluatedon → TPC-DS
confidence 88% · We conduct extensive evaluations on the TPC-DS benchmark
Auto-Scaling Controller → usesalgorithm → Factor-Informed Hurwicz Criterion
confidence 85% · preference-aware Auto-scaling Controller leveraging the Factor-Informed Hurwicz Criterion
ScaleSense → comparedwith → Snowflake
confidence 75% · cloud-native serverless architectures, exemplified by prominent systems such as Snowflake
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Cloud-native serverless data warehouses achieve fine-grained elasticity by decoupling storage from compute, yet determining the optimal resource allocation for highly heterogeneous ad-hoc queries remains a formidable industrial challenge. Our analysis of production workloads in Alibaba AnalyticDB exposes a costly ``provisioning trap'': the fear of catastrophic resource depletion drives users to blindly over-provision resources, wasting immense monetary budgets without alleviating non-CPU bottlenecks (e.g., I/O saturation). To break this impasse, we propose ScaleSense, a proactive, query-level resource scaling framework. Specifically, it features a multi-faceted query encoder that jointly models plan topologies and hardware specifications. Crucially, a quantile-based resource predictor estimates multi-dimensional physical footprints, acting as a reliable safety net for optimal resource scaling. An auto-scaling controller then navigates the performance-cost Pareto frontier, dynamically tailoring allocations to specific business priorities without requiring model retraining. Evaluations on over 1.36 million production queries show that ScaleSense achieves state-of-the-art prediction accuracy with good prediction interval coverage. By achieving a 76.7% relative improvement in optimal resource configuration selection over the best baseline, this approach addresses the critical performance-cost trade-off while maintaining low-overhead inference latency, confirming its practical performance in production deployments. Under the performance-optimization policy, ScaleSense satisfies user-defined performance requirements while reducing monetary cost by up to 5.22x.
Tags
Links
- Source: https://arxiv.org/abs/2608.07945v1
- Canonical: https://arxiv.org/abs/2608.07945v1
Trouble viewing inline? Open PDF directly →
Full Text
78,073 characters extracted from source content.
Expand or collapse full text
ScaleSense: Cost-Intelligent Scaling Framework via Learned Resource Estimation in Alibaba AnalyticDB Yifan Wu Zhejiang University † yifan.wu@zju.edu.cn Yuhan Li Zhenhua Wang Alibaba Cloud Computing lyh200442,wzh420090@alibaba- inc.com Ke Chen Lidan Shou ∗ Zonghao Chen Zhejiang University † ck,should,zhchen.cs@zju.edu.cn Liang Lin Alibaba Cloud Computing yibo.l@alibaba-inc.com Huan Li ∗ Gang Chen Zhejiang University † lihuan.cs,cg@zju.edu.cn ABSTRACT Cloud-native serverless data warehouses achieve fine-grained elasti- city by decoupling storage from compute, yet determining the op- timal resource allocation for highly heterogeneous ad-hoc queries remains a formidable industrial challenge. Our analysis of produc- tion workloads in Alibaba AnalyticDB exposes a costly “provision- ing trap”: the fear of catastrophic resource depletion drives users to blindly over-provision resources, wasting immense monetary budgets without alleviating non-CPU bottlenecks (e.g., I/O satura- tion). To break this impasse, we propose ScaleSense, a proactive, query-level resource scaling framework. Specifically, it features a multi-faceted query encoder that jointly models plan topologies and hardware specifications. Crucially, a quantile-based resource pre- dictor estimates multi-dimensional physical footprints, acting as a reliable safety net for optimal resource scaling. An auto-scaling con- troller then navigates the performance–cost Pareto frontier, dynam- ically tailoring allocations to specific business priorities without requiring model retraining. Evaluations on over 1.36 million produc- tion queries show that ScaleSense achieves state-of-the-art predic- tion accuracy with good prediction interval coverage. By achieving a 76.7% relative improvement in optimal resource configuration selection over the best baseline, this approach addresses the critical performance-cost trade-off while maintaining low-overhead infer- ence latency, confirming its practical performance in production deployments. Under the performance-optimization policy, Scale- Sense satisfies user-defined performance requirements while redu- cing monetary cost by up to 5.22×. PVLDB Reference Format: Yifan Wu, Yuhan Li, Zhenhua Wang, Ke Chen, Lidan Shou, Zonghao Chen, Liang Lin, Huan Li, Gang Chen. ScaleSense: Cost-Intelligent Scaling Framework via Learned Resource Estimation in Alibaba AnalyticDB. PVLDB, 19(12): 4063 - 4075, 2026. doi:10.14778/3827998.3828016 ∗ Huan Li and Lidan Shou are the corresponding authors. † The State Key Laboratory of Blockchain and Data Security This work is licensed under the Creative Commons BY-NC-ND 4.0 International License. Visit https://creativecommons.org/licenses/by-nc-nd/4.0/ to view a copy of this license. For any use beyond those covered by this license, obtain permission by emailing info@vldb.org. Copyright is held by the owner/author(s). Publication rights licensed to the VLDB Endowment. Proceedings of the VLDB Endowment, Vol. 19, No. 12% ISSN 2150-8097. 1 INTRODUCTION The On-Demand Scaling Challenge Over-provisioning Query256 CU → 5× Cost overrun Wasted resources, high cost Under-provisioning Query 16 CU 10× Latency or OOM Timeout, performance degradation ScaleSense: On-Demand Scaling Framework ❶ Query Plan DAG Aggregate HashJoinExchange ScanScanSort ❷ Multi-faceted Query Encoder Graph Transformer + Positional Encoding + Plan Tree Summarization ❸ Resource & Latency Predictor Bound Factors CPU Q₁₀Q₅₀Q₉₀ Mem Q₁₀Q₅₀Q₉₀ Disk Q₁₀Q₅₀Q₉₀ Net Q₁₀Q₅₀Q₉₀ Latency Q₁₀Q₅₀Q₉₀ ❹ Auto-Scaling Controller 16 CU32 CU64 CU128 CU256 CUPerformance-Cost Objective EncoderPredictorController Performance-Optimization Query128 CU →Fastest execution Best performance Cost-Optimization Query32 CU →Lowest cost Best Monetary Cost User-defined Query64 CU →Meets objective Custom trade-off Figure 1: The role of ScaleSense. The emergence of cloud-native serverless architectures, exempli- fied by prominent systems such as Snowflake [10], Amazon Redshift [4], and Alibaba Cloud AnalyticDB [8], has transformed data man- agement by leveraging storage-compute disaggregation to achieve fine-grained elasticity. In these environments, fixed-size clusters are replaced by elastic compute pools that can scale dynamically doi:10.14778/3827998.3828016 to match fluctuating workloads. To simplify management, com- putational resources are increasingly abstracted into standardized units, such as AnalyticDB Compute Units (ACUs) [1] or Redshift Processing Units (RPUs) [3]. This shift enables a transition from coarse-grained cluster resizing to granular, per-query resource al- location, offering more precise control over execution efficiency. However, this abstraction introduces a formidable processing chal- lenge: How can we predictively determine the optimal resource configuration for each ad-hoc query to strike a balance between execution performance and monetary cost? Despite the flexibility of serverless billing, production envir- onments are plagued by a profound mismatch between resource allocation and actual workload demands, forcing users into a costly provisioning trap. On one end of the spectrum, under-provisioning leads to catastrophic Out-of-Memory (OOM) failures. Our previous study [33] revealed that over 3,000 queries suffer OOMs daily in a single production region. Although this is a statistically negli- gible fraction (<0.0001%), each incident interrupts mission-critical workloads and squanders up to 17 CPU hours. In response to these reliability failures, users instinctively over-compensate by provi- sioning 2–3×the necessary resources as a crude safety margin, causing average cluster CPU utilization to plummet below 30%, as reported by Google [27] and Microsoft [9]. Crucially, this expens- ive over-provisioning is often futile. Production traces demonstrate that query bottlenecks frequently shift between memory-intensive joins, I/O-bound scans, and network-constrained shuffles [20,36]. Consequently, blindly throwing more Compute Units (CUs) at an I/O-bound query merely burns monetary budget without delivering any latency reduction. Breaking this vicious cycle requires precise, multi-dimensional foresight at the per-query level. Addressing these issues in the real production environment poses several critical technical challenges: •C1: Diverse Query Profiles. Production workloads are charac- terized by an immense variety of ad-hoc queries with highly dis- tinct and transient execution patterns, necessitating fine-grained, proactive prediction at the per-query level to accurately capture individual requirements before execution begins. • C2: Non-linear, Multi-dimensional Scaling Dynamics. The relationship between allocated resources and query perform- ance is likely non-linear. A query may be limited by different bottlenecks — CPU, memory bandwidth, disk I/O, or network throughput — at its different execution stages. Simply scaling up the CUs does not guarantee proportional performance gains due to Amdahl’s Law and I/O saturation, complicating the search for an optimal performance-to-cost equilibrium. •C3: Multi-Objective Optimization under User Perception. Resource provisioning in serverless environments is inherently subjective, as users often have conflicting preferences regarding performance and cost. Developing a universal policy is notori- ously difficult, necessitating a provisioning framework that sup- ports intuitive and tunable trade-off mechanisms, allowing users to explicitly define their tolerance for cost expansion and their requirements for performance acceleration. • C4: Reliability and Operational Constraints. In production, a resource allocation framework must be both reliable and efficient. Models without confidence estimation are risky to deploy. At the same time, any inference overhead must be negligible to avoid delay in query execution. Various approaches have been proposed for cloud resource man- agement, yet they often fall short of addressing these four chal- lenges simultaneously. Traditional reactive scaling methods [23] adjust capacity based on real-time telemetry, but suffer from an inherent detection lag that fails to prevent resource exhaustion. Predictive scaling models [15] forecast future demand from his- torical trends, but they struggle with the structural diversity of ad-hoc queries whose execution plans differ from historical pat- terns. Some commercial platforms [4,10] utilize elastic auto-scaling and machine learning-driven workload management. While these systems can estimate query-level resource demands for admission control and memory allocation, their scaling logic remains primar- ily cluster-centric or based on coarse-grained resource tiers. They lack the ability to balance multi-dimensional footprints with user- tunable cost-performance trade-offs, which is necessary to optimize efficiency for ad-hoc workloads. Optimization-based methods like CherryPick [2] utilize Bayesian search to find ideal configurations, but their absolute reliance on multiple trial runs makes them im- practical for production deployment. To break this impasse, we propose ScaleSense (Figure 1), an end-to-end, preference-aware auto-scaling framework that shifts the paradigm from deterministic, reactive provisioning to prob- abilistic, proactive query-level foresight. First, to overcome work- load heterogeneity (C1) and diverse hardware landscapes (C2), we design a Multi-faceted Query Encoder. Unlike traditional stat- istical models, it directly captures the hierarchical topology of execution plan Directed Acyclic Graphs (DAGs) and fuses them with runtime statistics and hardware specifications into a unified latent space. Second, to handle non-linear bottlenecks (C2) and operational uncertainty (C4), we introduce a Quantile Resource Predictor. Moving beyond fragile point estimates, it explicitly pre- dicts statistical bounds for four fundamental physical constraints. Equipped with a zero-classifier for sparse data, it acts as a prevent- ative feasibility filter, proactively pruning configurations prone to OOM and ensuring robust execution bounds for the remaining vi- able options. Third, to resolve the multi-objective scaling problem under varying user preferences (C3), we introduce a preference- aware Auto-scaling Controller leveraging the Factor-Informed Hur- wicz Criterion (FIHC) to formalize resource provisioning as a con- strained multi-objective optimization problem. By incorporating both performance-oriented and cost-efficient operational policies, the controller identifies optimal resource specifications that adhere to user-defined performance and budget thresholds, enabling the selection of Pareto-optimal configurations tailored to diverse user priorities without retraining the prediction models. Empirical evaluations on over 1.36 million production quer- ies confirm ScaleSense’s effectiveness across all evaluation di- mensions. It not only achieves state-of-the-art accuracy, reducing median Q-Error for resource estimation by up to 78%, but funda- mentally ensures operational safety by maintaining good predic- tion interval coverage. In terms of auto-scaling efficiency, Scale- Sense achieves a 76.7% improvement in CU configuration recom- mendation accuracy over the best baseline. Notably, under the performance-optimization policy, it satisfies user-defined perform- ance requirements while reducing monetary cost by up to 5.22× compared to existing methods. Our key contributions are summarized as follows: • We design an on-demand auto-scaling framework that integ- rates a multi-faceted query encoder, a quantile-based resource predictor, and a preference-aware auto-scaling controller. Scale- Sense facilitates fine-grained performance–cost trade-offs, em- powering users to dynamically navigate varying budget and latency constraints without the overhead of model retraining. •Moving beyond black-box latency estimation, we develop a uni- fied performance and resource prediction architecture that pre- dicts query latency alongside four fundamental performance- bound factors. We uniquely integrate a zero-inflated classifier to handle extreme data sparsity, ensuring robustness across hetero- geneous workloads. • We pioneer a risk-controlled scaling mechanism based on Factor- Informed Hurwicz Criterion. By using calibrated prediction in- tervals as proactive safety guardrails, our framework predictively prunes configuration candidates that pose a high risk of memory pressure or hardware saturation. •We conduct extensive evaluations on the TPC-DS benchmark and massive real-world production datasets. Results demonstrate that ScaleSense achieves strong multi-dimensional prediction accuracy with negligible inference overhead. The remainder of this paper is structured as follows: Section 2 introduces the background. Section 3 distills empirical design insights, motivating the ScaleSense framework detailed in Sec- tion 4. Section 5 provides comprehensive evaluations, followed by related work in Section 6. Section 7 presents failure analysis and operational lessons. Section 8 concludes this paper. 2 BACKGROUND This section first describes the architectural design of serverless AnalyticDB with ScaleSense integration, then formalizes the pre- diction and scaling problems addressed in this work. 2.1 AnalyticDB’s Serverless Query Execution AnalyticDB is a cloud-native, real-time data warehouse built to handle heterogeneous workloads with diverse resource demands. To achieve high performance and elasticity, AnalyticDB follows a storage-compute disaggregated architecture, similar to industrial counterparts like Snowflake [10], and Amazon Redshift [4]. As shown in Figure 2, the system is organized into three functional layers. The Access Layer handles SQL entry, connection manage- ment, and query optimization, employing a Parser and an Optimizer to transform SQL statements into physical execution plans. The Compute Layer executes query tasks using a distributed engine con- sisting of stateless executor nodes that can be scaled on demand, while the Storage Layer consists of storage nodes from distributed storage systems to support high-throughput analytical scans. To simplify cloud resource management, AnalyticDB abstracts computational capacity into Compute Units (CUs). Each CU rep- resents a standardized bundle of CPU, memory, and I/O resources allocated at the per-query level. AnalyticDB defines one CU as one Compute Layer Scheduler) (Parser, Optimizer, Access Layer Storage Layer Serverless Query Execution & Prediction Pipeline SQLQuery Optimizer ScaleSense Multi-faceted EncoderQuantile Predictor Scaling Controller Scheduler Executors Elastic Resource Management Service Request / Release ACUs Tiered Resource Pool Evaluation Metrics Optimized Latency Optimal Cost ACU Decision (XIHE Execution Engine) (Xuanwu Storage Engine) (Data Lake) Executor ExecutorExecutor Figure 2: The architecture of AnalyticDB, highlighting Scale- Sense as the proactive decision boundary between query optimization and resource scheduling. CPU core paired with 4GB of main memory. When a query is sub- mitted, the system assigns a specific number of CUs for execution. CU availability is ensured by the IaaS layer through an ECS warm pool that maintains pre-provisioned capacity for fast allocation. This design provides second-level provisioning readiness, allowing pre-warmed resources to be assigned to a query almost instant- aneously. Resource exhaustion and admission control are handled by the infrastructure scheduler, independent of the per-query CU sizing decision. Under extreme load, queries wait in the scheduler queue before CU allocation, and the sizing decision is invoked only after the query is admitted. Once allocated, each CU is provisioned as an isolated lightweight VM on ECS infrastructure, with CPU, memory, and I/O bandwidth reserved for the assigned query. Provi- sioning time is not billed to the customer, and after execution, the CU is returned to the warm pool for reuse in continuous workloads. To achieve cost-intelligent scaling, ScaleSense is injected dir- ectly into the critical execution path as a proactive decision bound- ary between the Access and Compute layers. When the Optim- izer generates a physical DAG for a query, the Multi-faceted Query Encoder captures its structural topology and statistical features. Rather than relying on reactive telemetry, the Quantile Resource Predictor translates these features into probabilistic, multi-dimensional execution bounds. Then the Auto-Scaling Con- troller evaluates user-defined preferences alongside the predicted resource distributions to dynamically determine the optimal CU configuration. Finally, this decision is passed to the Scheduler to provision the exact required capacity from the Tiered Resource Pool, while Executors carry out the actual execution. Deployment Status. The default performance optimization policy of the CU recommendation mechanism, which accelerates performance under a given monetary cost budget, is fully deployed in production to serve all customers, while its customizable recom- mendation feature — balancing monetary cost and performance — has been rigorously validated through controlled experiments and real customer workloads. 2.2 Problem Statement Effective on-demand scaling requires precise query performance forecasting across diverse hardware configurations [35]. As Section 3 demonstrates, ad-hoc queries rarely scale linearly due to shifting, Figure 3: Latency distribution of TPC-DS 1 TB queries across six CU configurations (16, 32, 64, 128, 256, and 512 CUs). query-specific hardware bottlenecks. To overcome the limitations of monolithic, black-box latency models, we decompose execution dynamics into observable dimensions. Guided by our empirical production analysis in Section 3, we explicitly isolate four physically grounded bottleneck indicators, namely (i) CPU time, (i) peak memory size, (i) table scan volume (disk I/O), and (iv) shuffle size (network I/O), to mechanistically forecast the ultimate optimization target: (v) end-to-end query latency. We formulate the performance and resource estimation problem as follows. Problem 1 (Performance and Resource Estimation). Given a query푞and a candidate CU configuration푎 ∈ A, the objective is to learn a predictive mapping푓 휃 (푞,푎) → ˆ 푦 푑 for each physical resource dimension푑 ∈ D 푟 = cpu, mem, disk, net, alongside the query latency ˆ 푦 lat . Crucially, these intermediate resource estimates ˆ 푦 푑 푑∈D 푟 are not merely passive metrics; they serve as bottleneck- aware, foundational signals that explicitly guide the downstream latency prediction (detailed in Section 4.2). For Problem 1, our primary point-estimation metric is Q-error, defined asmax( ˆ 푦/푦, 푦/ ˆ 푦), which symmetrically penalizes over- and under-estimation of the predicted value. We use Q-error only to evaluate the accuracy of the resource prediction. The asymmetric operational consequences of prediction errors are handled down- stream by the auto-scaling controller in Section 4.3. Equipped with these multi-dimensional forecasts, we must trans- late estimated latency and cost into actionable resource config- urations fromA. Instead of a fixed scoring function, we adopt a constraint-based optimization approach that explicitly incorporates user-defined elasticity parameters to navigate the performance-cost trade-off. We formalize this on-demand scaling problem as follows. Problem 2 (On-Demand Scaling with User Preference). Let A=푎 1 ,푎 2 , . . .,푎 푘 denote the discrete set of candidate CU config- urations. For a query푞provisioned with configuration푎, letCU(푎) denote the assigned compute units,퐿 푎 the predicted latency, and 퐶 푎 = CU(푎)× 퐿 푎 the projected monetary cost. The objective is to select an optimal configuration푎 ∗ ∈ Athat strictly adheres to the user’s operational constraints. We characterize this trade-off using two user-defined parameters: the Cost Scaling Factor (휖) and the Performance Scaling Factor (휌), both normalized against a predefined baseline configuration푎 푏푎푠푒 ∈ A. Depending on the operational priority, the system supports two complementary optimization policies: (1)Performance Optimization (PO) Policy: The user seeks per- formance speedup within a specific budget expansion. The goal is to minimize execution latency while ensuring the cost remains within the tolerance 휖 and the speedup meets the target 휌: 푎 ∗ = arg min 푎∈A 퐿 푎 | (퐶 푎 /퐶 푏푎푠푒 ≤ 휖)∧(퐿 푏푎푠푒 /퐿 푎 ≥ 휌).(1) (2) Cost Optimization (CO) Policy: The user prioritizes budget savings, provided the performance degradation remains within a predefined acceptable threshold. The goal is to minimize the monetary cost while ensuring휌is met, and the cost ceiling휖is respected: 푎 ∗ = arg min 푎∈A 퐶 푎 | (퐿 푎 /퐿 푏푎푠푒 ≤ 휌)∧(퐶 푏푎푠푒 /퐶 푎 ≥ 휖).(2) By unifying preferences into휖and휌, our framework provides a consistent interface for users to navigate the Pareto front, regardless of whether their primary goal is acceleration or frugality. Our monetary cost model follows the billing model of Analyt- icDB Serverless [31]. In this model, query execution consumes compute resources measured by CU-time, i.e., the allocated com- pute units multiplied by their usage time. Accordingly,퐶 푎 captures the cost component of executing a query under CU configuration푎, which is the component directly affected by ScaleSense’s per-query CU allocation decision. This model is not intended to represent the entire cloud bill. In practice, users may also incur storage or data- transfer charges, and these factors depend on deployment-specific usage. Therefore, these factors are excluded from the optimization objective. In our setting, CU resources are allocated from a warm pool, so provisioning latency is treated as an operational scheduling issue rather than a separately charged user cost. 3 EMPIRICAL DESIGN INSIGHTS In this section, we derive the foundational architectural motivations for ScaleSense through an empirical analysis of both the TPC-DS benchmark and massive production query logs. As a classical OLAP benchmark, TPC-DS is well-suited to repres- ent typical analytical query workloads. We execute all 99 TPC-DS queries at the 1 TB scale factor under six CU configurations (16, 32, 64, 128, 256, and 512 CUs). Each query is run more than six times in strict isolation (with caches flushed and resources exclusively reserved), yielding the latency distributions shown in Figure 3. Across all queries, scaling from 16 to 512 CUs yields a latency re- duction in 88% of cases; however, scaling from 256 to 512 CUs alone yields a reduction in latency in only 53% of cases. This saturation suggests that the performance–resource scaling relationship is governed by distinct performance bounds across different CU ranges. To isolate the specific mechanistic bounds dictating these non- linear scaling behaviors, we examine the resource footprints of the TPC-DS workload. Table 1 presents quantitative evidence for four representative queries across scaling tiers, showing how different Figure 4: Quantile distribution of query latency and key factors across the CPU, memory, disk I/O, and network dimensions. Table 1: Quantitative resource evidence across scaling tiers. Bound Type Query Metric16 CU 128 CU 512 CU CPU-Bound Q28 CPU Time (Hours)2.8315.5330.00 Peak Memory (GB)10.841.9131.0 Table Scan (GB)109.0109.0109.0 Shuffle Size (GB)1.952.211.93 Memory-Bound Q78 CPU Time (Hours)5.1712.6914.97 Peak Memory (GB)147.0254.0410.0 Table Scan (GB)106.0106.0106.0 Shuffle Size (GB)174.0171.0176.0 Network-Bound Q23 CPU Time (Hours)3.5613.5315.58 Peak Memory (GB)35.290.0280.0 Table Scan (GB)211.0211.0211.0 Shuffle Size (GB)370.0368.0364.0 Disk I/O-Bound Q14 CPU Time (Hours)11.4714.5617.08 Peak Memory (GB)13.890.1296.0 Table Scan (GB)187.0187.0187.0 Shuffle Size (GB)2.077.149.63 execution plans are gated by distinct physical constraints. The CPU- boundQ28involves complexCOUNT(DISTINCT)sub-queries where deduplication logic consumes extensive cycles, evidenced by CPU Time scaling from 2.83 to 30 hours at 512 CU while the shuffle size remains negligible (1.93 GB). In contrast, the memory-bound Q78utilizes multi-channel joins necessitating massive hash tables; its peak memory size (410 GB) is nearly 4×its 106 GB scan volume, making memory capacity critical to avoid disk spills. Moreover, Q23is network-bound due to global aggregations that trigger in- tense cross-node shuffling; its invariant 364 GB Shuffle Size signi- ficantly exceeds its 211 GB scan volume, establishing a physical latency floor that resists further compute expansion. Finally,Q14 is disk I/O-bound and benefits from increased aggregate I/O band- width to handle its 187 GB scan volume, transitioning from an I/O-constrained bottleneck to a compute-balanced state. These find- ings consolidate into our first core insight: Insight 1. Accurately predicting query latency requires account- ing for two complementary sources of uncertainty: (i) the intrinsic run- to-run variability of query execution time (Figure 3), and (i) resource- configuration-dependent performance bounds along several primary dimensions — CPU, memory, disk I/O, and network — whose dom- inant factors are CPU time, peak memory size, table scan volume, and shuffle size, respectively (Table 1). Because latency exhibits an inherent run-to-run distributional range rather than collapsing to a single value, a well-calibrated point estimator cannot adequately quantify execution uncer- tainty. To address this, ScaleSense employs a quantile resource predictor (Section 4.2) to explicitly capture the conditional latency distribution. Since execution variability drops sharply outside ex- treme quantiles (e.g., the 10th and 90th percentiles), explicitly mod- eling those four dominant bottleneck factors substantially simplifies learning the complex resource–performance mapping. To further understand these dynamics at scale, we conducted a quantile-level distributional analysis of query latency and the four key performance bounds, sampling one million long-running queries (>1 s) from the AnalyticDB production environment. The results, partitioned into 5%-wide quantile bins, are presented in Figure 4. As Figure 4 illustrates, CPU time suffers from a tail ef- fect even more pronounced than latency itself, driven by massive deviations in the upper quantiles. Conversely, peak memory size, table scan volume, and shuffle size exhibit distinct zero-inflation, with exact-zero values accounting for 11.4%, 45.5%, and 40.2% of observations, respectively. Notably, queries that record no disk I/O are mainly those whose storage reads are fully eliminated by filter- ing; for example, predicate filtering or runtime filters may prune all candidate data before scan materialization, so the final recorded table-scan bytes are zero. We summarize the second core insight: Insight 2. Performance-bound factors exhibit extreme distri- butional skew and high sparsity. While query latency and CPU time display severe heavy-tailed distributions, the I/O and memory dimensions contain massive exact-zero regions. This profound distributional skew invalidates standard re- gression modeling. First, to handle the high sparsity, the Scale- Sense resource predictor must incorporate a zero-value classifier (Section 4.2); otherwise, exact-zero targets will introduce extreme bias and distort the loss gradients for positive-valued samples. Second, because different resource bottlenecks trigger distinct ad- verse scenarios at their extremes (e.g., peak memory spikes cause fatal OOM crashes, whereas CPU spikes induce severe contention), our architecture must explicitly model the extreme quantile bound- aries (e.g.,푃 10 and푃 90 ) rather than just the median, providing the risk-aware safety net necessary for stable auto-scaling. 4 SCALESENSE DESIGN This section presents the design of ScaleSense, an on-demand scaling framework for serverless data warehouse environments. As illustrated in Figure 5, ScaleSense operates as an integrated pipeline comprising three core components: (1) the Multi-faceted Query Encoder (Section 4.1), which transforms raw query plans into compact vector representations; (2) the Quantile Resource Predictor (Section 4.2), which provides multi-dimensional resource forecasts with calibrated uncertainty quantification; and (3) the Auto-Scaling Controller (Section 4.3), which translates these probabilistic estim- ates into compute unit configuration decisions. Query Plan + CU Config ❶Multi-faceted Query Encoder Graph Transformer + Laplacian PE + Plan Summarization Plan embedding z (64D) + statistical features s (157D)→f∈ ℝ²¹ ❷Quantile Resource Predictor Stage 1: Bound Factor PredictorStage 2: Latency Predictor Quantile model × CPU, Mem, Disk, Net→[Q₁₀, Q₅₀, Q₉₀] ❸Auto-Scaling Controller Factor-Informed Hurwicz: adaptiveλblending Q₁₀/ Q₉₀ Scoring→a* (optimal CU recommendation) Figure 5: Overall framework of ScaleSense. 4.1 Multi-faceted Query Encoder Query plans are naturally represented as directed acyclic graphs (DAGs), where nodes correspond to operators and edges represent data flow. Effectively encoding this structure is crucial for accur- ate prediction. As shown in Figure 6, the encoder comprises three stages: node feature extraction with Laplacian Positional Encoding (LPE), a Plan Graph Transformer that produces a fixed-dimensional plan embedding, and a plan tree summarization strategy for hand- ling large query plans. Node Feature Extraction with LPE. Graph neural networks have shown great promise in representation learning for structured data. Recently, Lyu et al. [18] demonstrated that Laplacian Positional Encoding (LPE) significantly improves the ability of Transformers to capture global topological properties of graphs. Query plans share similar structural characteristics with the graphs studied in [18]—they are directed acyclic graphs where the relative position of a node (e.g., whether a Join is at the bottom or top of the tree) fundamentally alters its resource impact. Building on this insight, we adapt the LPE-based Transformer architecture for query plan encoding. Unlike prior work that uses tree convolutions [19] (local-only) or height encodings [37] (vertical- only), our approach leverages the graph Laplacian to capture the full global topology of the query plan. For each operator node (denoted by index푣) in the plan DAG, we extract an 11-dimensional feature vector: x 푣 =[op_type, log(rows), log(bytes), flags, structural],(3) encompassing (1)op_type: Operator type index, normalized by the total number of operator categories (19 types including HashJoin, TableScan, Aggregate, Exchange, Sort, etc.); (2)log(rows), log(bytes): Log-transformed estimated output rows and estimated output bytes from optimizer statistics, each normalized by the respective max- imum observed value; (3) flags: Binary indicators for operator cat- egories (e.g., is_join) and (4)structural: Tree depth, parallelism de- gree, and selectivity estimates. To capture the global structure of the plan DAG, we compute LPE based on the graph Laplacian matrix. While spectral analysis typically treats the graph as undirected, this does not result in crit- ical information loss for our task. The global topology (e.g., depth, Plan DAG Agg Join Exchange ScanScanSort ↓ Node Feature Vectors Laplacian PE Adjacency Matrix Normalized Laplacian Eigen Decomposition Positional Encoding Graph Transformer Input Projection Self-Attention Mean Pooling z ∈ ℝ⁶⁴ Plan Tree Summarization for Large Plans Subtree split → chunk encode → weighted average → Graph Transformer → z ∈ ℝ⁶⁴ Concat: z (64D) + stat features s (157D) → f ∈ ℝ²¹ Figure 6: Architecture of the Multi-faceted Query Encoder. width, bottleneck nodes) captured by the Laplacian spectrum is direction-independent but crucial for resource estimation. Further- more, the Transformer’s self-attention mechanism implicitly learns directional dependencies during training, complementing the struc- tural bias provided by LPE [18]. Given the adjacency matrix A∈R 푛×푛 of the plan DAG (treated as undirected for spectral analysis), we compute the normalized Laplacian: ̃ L=I−D −1/2 AD −1/2 ,where D is the degree matrix. We compute the eigen-decomposition ̃ L=UΛU ⊤ and use the eigen- vectors corresponding to the푘smallest non-zero eigenvalues as positional encodings PE(푣)=[U 푣,1 , U 푣,2 , . . ., U 푣,푘 ]. The eigenvectors of the Laplacian encode structural information about node centrality, connectivity patterns, and graph partitioning. Nodes with similar structural roles (e.g., leaves, roots, bottleneck operators) receive similar positional encodings, enabling the model to generalize across query plans with different sizes but similar topological patterns. Plan Graph Transformer Architecture. The Plan Graph Trans- former processes the sequence of node features augmented with positional encodings (Figure 6), i.e., h (0) 푣 =W 푥 x 푣 +W 푝 PE(푣).Mul- tiple Transformer encoder layers apply self-attention across all nodes: h (ℓ+1) = TransformerLayer(h (ℓ) ). The final plan embedding is obtained via mean pooling over all node representations, i.e., z= 1 |푉| ∑︁ 푣∈푉 h (퐿) 푣 .This aggregation strategy produces a fixed-dimensional plan embedding z∈R 64 regardless of the number of operators in the plan. Mean pooling provides consistent performance across varying plan sizes while being computationally efficient. Plan Tree Summarization for Large Plans. Production query plans can contain hundreds of operators, making direct Trans- former encoding prohibitively expensive (O(푁 2 )self-attention). To handle such plans efficiently, we introduce a plan tree summariza- tion strategy that partitions the plan DAG into manageable chunks while preserving local structural information. The key idea is to split the plan along subtree boundaries: we perform a DFS traversal, compute the sub-tree size of each node, and greedily assign complete sub-trees to chunks until a size budget퐶 (default 200 nodes) is reached. This ensures that each chunk retains the parent-child relationships within its subgraph, preserving the local topology that the Transformer relies on. Each chunk is then independently encoded by the Plan Graph Transformer, and the Algorithm 1: Encoding with Plan Tree Summarization Input: Plan DAG nodes푉 , chunk size budget퐶 Output: Plan embedding z ∈R 64 1 if |푉| ≤ 퐶 then 2return PlanGraphTransformer(푉) 3 Compute subtree size sz(푣) for each 푣 ∈ 푉 via bottom-up traversal 4 S ← ∅; buf← ∅ 5 foreach node 푣 in DFS order do 6if sz(푣) ≤ 퐶 then 7if |buf|+ sz(푣)> 퐶 and buf≠ ∅ then 8S ← S∪buf; buf← ∅ 9buf← buf∪ Subtree(푣) 10else 11Add 푣 alone to buf; push children to stack 12 S ← S∪buf 13 foreach chunk푐 푖 ∈ S do 14Build local adjacency A 푖 (intra-chunk edges only) 15z 푖 ← PlanGraphTransformer(푐 푖 , A 푖 ) 16 z← ∑︁ 푖 |푐 푖 | ∑︁ 푗 |푐 푗 | · z 푖 17 return z final plan embedding is obtained by a weighted average of chunk embeddings, where the weight of each chunk is proportional to its node count. Algorithm 1 details this procedure. Complexity Analysis. This approach reduces the per-query en- coding cost fromO(푁 3 )toO(푁퐶 2 ), where푁is the total number of operators and퐶is the chunk budget. The dominant cost in full-plan encoding is the Laplacian eigen-decompositionO(푁 3 ), followed by Transformer self-attention (O(푁 2 푑)). With plan tree summariz- ation, each of the 푀=⌈푁/퐶⌉ chunks independently computes its local Laplacian PE (O(퐶 3 )each) and runs self-attention (O(퐶 2 푑) each), yielding a total cost ofO(푁퐶 2 + 푁퐶푑). Since퐶is a fixed constant (default 200), the complexity is linear in 푁 for fixed퐶. After obtaining the structural feature vector of the query plan via the Graph Transformer, we concatenate it with a plan-level stat- istics feature vector (adopted from prior work [33]) and hardware configuration information (e.g., the CU configuration) to form the final representation. A detailed description of the plan statistics features is provided elsewhere [5]. 4.2 Quantile Resource Predictor Query Feature Vectorf∈ℝ²¹ Stage 1: Bound Factor Predictor Quantile Regression ModelZero-Inflated Classifier CPU Mem DiskNet [Q₁₀, Q₅₀, Q₉₀] per dimension Concat: f (221D) ⊕ Stage 1 output → Stage 2 input Stage 2: Latency Predictor Quantile Regression → Latency [Q₁₀, Q₅₀, Q₉₀] Figure 7: Architecture of the Quantile Resource Predictor. The core insight of ScaleSense is decomposing resource predic- tion into two stages, as illustrated in Figure 7: performance-bound factor prediction (first stage) and latency prediction (second stage). Bound Factor Predictor (Stage 1). The Bound Factor Predictor predicts the performance bounds of a query across four dimensions, with uncertainty quantification for all dimensions. Critically, pre- dictions are conditioned on the target CU configuration, as some bounds (notably Disk I/O) depend on available memory. The input is f=[z∥s], where z is the 64-dimensional plan embedding and s is a 157-dimensional vector of statistical features extracted from the optimizer plan (including operator counts, cardinality estim- ates, hardware configuration, and aggregate plan statistics). The concatenated input f∈R 221 captures both structural and statistical information. We employ gradient-boosted quantile regression [26] to pre- dict three quantiles for each dimension (Figure 7): [푄 (푑) 10 ,푄 (푑) 50 ,푄 (푑) 90 ]=[XGB (푑) 휏 (f)] 휏∈0.1,0.5,0.9 ,(4) where∀푑 ∈ cpu, mem, disk, net. For each dimension and quantile level, an independent XGBoost (XGB) model is trained on log-transformed targets. Monotonicity (푄 10 ≤ 푄 50 ≤ 푄 90 ) is enforced at inference time by clipping: 푄 (푑) 10 ← min(푄 (푑) 10 ,푄 (푑) 50 ), 푄 (푑) 90 ← max(푄 (푑) 90 ,푄 (푑) 50 ).(5) We adopt the 10th and 90th percentiles to construct an 80% pre- diction interval. This choice is informed by our empirical analysis (Section 3), which shows that the bulk of execution variability con- centrates within this range, while the tails beyond Q10 and Q90 may be caused by transient runtime noise. This design is critical for risk-controlled allocation: memory under-estimation leads to OOM failures, which are far more catastrophic than CPU under- estimation (which merely causes slowdowns). By providing predic- tion intervals for memory usage, ScaleSense enables the scheduler to provision memory conservatively for memory-sensitive queries. To ensure model fidelity, all training labels are empirically ac- quired directly from query execution logs, avoiding error-prone heuristic decomposition or estimation. The multi-dimensional phys- ical constraints are defined as follows: (i)퐵 cpu , the total CPU time (ms) captured via execution telemetry; (i)퐵 mem , the peak memory footprint (bytes) recorded by task-level instrumentation; (i)퐵 disk , the disk I/O volume (bytes) aggregated from table scan counters; and (iv)퐵 net , the network I/O payload extracted from shuffle coun- ters. Unlike approaches that decompose observed latency into latent resource components, we predict known, measurable quantities recorded by the query engine during execution. This makes the system debuggable: if a prediction is wrong, we can identify which dimension was mispredicted. Latency Predictor (Stage 2). The Latency Predictor is a quantile regression model that maps the Stage 1 outputs and features to end-to-end latency with uncertainty quantification. It takes as input the concatenation of scaled features and the full Stage 1 quantile predictions, and outputs latency quantiles directly: [ ˆ 퐿 푄 10 , ˆ 퐿 푄 50 , ˆ 퐿 푄 90 ]= LatencyPredictor([f 푠푐푎푙푒푑 ∥flatten( ˆ Q 푆1 )]), (6) where ˆ Q 푆1 ∈R 4×3 denotes the Stage 1 quantile predictions across four dimensions and three quantile levels. This design has two key advantages: 1) End-to-end Supervision: The model is trained directly on observed latency, avoiding the pitfalls of intermediate efficiency coefficients that can lead to unin- terpretable compensation effects; 2) Native Uncertainty: The Stage 2 model produces its own calibrated prediction intervals for latency, rather than relying on propagation of Stage 1 quantiles through a deterministic mapping. Both stages use quantile loss (pinball loss) as the training ob- jective. For a target quantile level 휏 : L 휏 (푦, ˆ 푦)= ︄ 휏(푦− ˆ 푦)if푦 ≥ ˆ 푦 (1−휏)( ˆ 푦−푦)if푦< ˆ 푦 .(7) XGBoost natively optimizes the pinball loss through second- order gradient boosting. For multiple quantiles휏 ∈ 0.1,0.5,0.9, separate models are trained for each quantile level. The 80% prediction interval is constructed as[푄 10 ,푄 90 ]. The me- dian푄 50 serves as the point estimate. The interval width푄 90 −푄 10 quantifies prediction uncertainty: wider intervals indicate higher uncertainty, suggesting more conservative resource allocation. For resource dimensions with high zero rates—peak memory (∼11.4% zeros), table scan volume (∼45.5% zeros), and shuffle size (∼40.2% zeros)—we employ a Hurdle Model approach. A lightweight gradient-boosted classifier first predicts whether the resource con- sumption is zero. For samples classified as zero, the corresponding Stage 1 quantile predictions are set to zero before being passed to Stage 2. The quantile regression model is trained only on non-zero samples for these dimensions (via a loss mask that excludes zero- valued targets), allowing it to focus on predicting the conditional distribution given non-zero consumption. 4.3 Auto-Scaling Controller Given the quantile predictions from the quantile resource predictor for each candidate CU configuration, the Auto-Scaling Controller selects the configuration that minimizes the optimization objective defined in Problem 2. The key challenge is: which latency estimate should be used as 퐿 푎 in the CU configuration selection? Using the median ˆ 퐿 푄 50 ignores prediction uncertainty, while using the upper bound ˆ 퐿 푄 90 is overly conservative. We propose a Factor-Informed Hurwicz criterion that adaptively blends optimistic and pessimistic latency estimates based on resource pressure signals from Stage 1. Candidate Enumeration. For each query푞, we evaluate candidate CU configurationsA=푎 1 ,푎 2 , . . .,푎 푘 . For each candidate푎, the Two-Stage Quantile Resource Predictor produces latency quantiles ( ˆ 퐿 푄 10 푎 , ˆ 퐿 푄 50 푎 , ˆ 퐿 푄 90 푎 )and Stage 1 factor quantiles( ˆ 푊 푄 10 푎,푑 , ˆ 푊 푄 50 푎,푑 , ˆ 푊 푄 90 푎,푑 ) for each resource dimension 푑 . Factor-Informed Hurwicz Criterion. The classical Hurwicz cri- terion [13,14,32] blends the best-case and worst-case outcomes using a fixed optimism parameter. We extend this idea by making the blending parameter adaptive — informed by both the user pref- erence훼and the resource pressure signals from Stage 1 predictions. For each candidate configuration푎, we compute a per-query blending parameter휆(푞,푎) ∈ [0,1]that controls the interpolation between the optimistic (푄 10 ) and pessimistic (푄 90 ) latency estimates: ˆ 퐿 푎 = 휆(푞,푎)· ˆ 퐿 푄 10 푎 +(1− 휆(푞,푎))· ˆ 퐿 푄 90 푎 .(8) The blending parameter is composed of two signals: 휆(푞,푎)= 훼 · 휆 pressure (푞,푎)+(1− 훼)· 휆 position (푞,푎),(9) where 훼 is the user preference coefficient from Problem 2. Resource Pressure Signal (휆 pressure ). This signal captures how heavily the candidate configuration is loaded relative to other can- didates. We compute per-CU resource pressure for memory and CPU using the pessimistic (Q90) Stage 1 predictions: 푝 mem (푎)= ˆ 푊 푄 90 푎,mem CU(푎) , 푝 cpu (푎)= ˆ 푊 푄 90 푎,cpu CU(푎) .(10) Each pressure value is min-max normalized across candidates, and the pressure signal is: 휆 pressure (푞,푎)= 1− 1 2 (︁ ̃ 푝 mem (푎)+ ̃ 푝 cpu (푎) )︁ ,(11) where ̃ 푝 denotes the normalized pressure. Configurations with lower per-CU resource pressure receive higher휆 pressure (more op- timistic), reflecting the intuition that under-loaded configurations are less likely to experience performance degradation. We adopt CPU and memory for the Resource Pressure Signal because these two dimensions are directly tied to the CU configuration in Analyt- icDB, whereas the other two factors (disk I/O and network I/O) are not governed by the CU specification. Factor Position Signal (휆 position ). This signal captures the skew- ness of the Stage 1 prediction intervals. For each resource dimension 푑, we compute the relative position of the median within its predic- tion interval: rp 푑 (푎)= ⎡ ⎢ ⎢ ⎢ ⎢ ⎣ ˆ 푊 푄 50 푎,푑 − ˆ 푊 푄 10 푎,푑 ˆ 푊 푄 90 푎,푑 − ˆ 푊 푄 10 푎,푑 ⎤ ⎥ ⎥ ⎥ ⎥ ⎦ 1 0 .(12) The position signal is the complement of the average relative posi- tion: 휆 position (푞,푎)= 1− 1 |D 푟 | ∑︂ 푑∈D 푟 rp 푑 (푎).(13) When the median is close to푄 10 (left-skewed interval),rp 푑 is small and휆 position is high, indicating that the model is confident the true value is near the optimistic end. When the median is close to푄 90 , rp 푑 is large and 휆 position is low, signaling higher downside risk. Under loose constraints (훼=0), the dominant risk is prediction error;휆 position steers ˆ 퐿 푎 toward푄 90 when prediction intervals are right-skewed, guarding against over-optimism. Under tight con- straints (훼=1), the dominant risk is resource contention;휆 pressure penalizes configurations with high per-CU load, preventing toler- ance violations from memory spilling or CPU throttling. 5 EVALUATION We evaluate ScaleSense across prediction accuracy, auto-scaling efficiency, and system overheads, addressing three core questions: EQ1PredictionPerformanceComparison(Section5.2): How ac- curately does ScaleSense predict query latency and resource consumption compared to state-of-the-art baselines? EQ2EfficiencyofAuto-Scaling(Section5.3): How effectively does ScaleSense achieve user-preferred performance-cost trade- offs compared to the baselines? EQ3 TimeOverheads(Section5.4): What are the empirical train- ing and inference time costs of ScaleSense? 5.1 Experimental Settings Hardware Setup. All queries are executed on Alibaba Cloud Ana- lyticDB instances. All model training and inference experiments are conducted on a single machine equipped with an Intel Xeon Platinum 8163 CPU (64 cores, 2.50 GHz), and 252 GB RAM. Baselines. Our experimental evaluation is organized into two parts. For query performance and resource estimation (Part I), we compare against four competitive baselines: GTN, XGB, MLP, and LGBM. For on-demand scaling evaluation (Part I), we also include a heuristic rule (LSR) and S-naive. We introduce each baseline as follows: •Graph Transformer Network (GTN) [17,18]: Recent stud- ies [17,18] have shown that Graph Transformer Networks achieve state-of-the-art performance in query plan encoding and are widely adopted for cardinality estimation and latency prediction. •XGBoost-based Predictor (XGB) [21,33]: XGBoost is extens- ively used for latency and memory demand estimation in RAIS [21], the state-of-the-art intelligent scaling system. A recent study on memory-overloading queries [33] further demonstrates that XG- Boost is the best-performing model for memory estimation. This baseline applies XGBoost regression on the query feature vector, following the same details as SafeLoad [33]. •MLP-based Predictor (MLP) [24]: Multi-layer perceptrons are widely used for resource estimation due to their low online infer- ence overhead. LearnedWMP [24] employs an MLP for memory demand prediction. This baseline applies an MLP on the query feature vector. •LightGBM-based Predictor (LGBM): LightGBM is commonly regarded as an alternative to XGBoost and frequently serves as a baseline in the resource estimation literature [24, 33]. •Linear Scaling Rule (LSR): LSR is a heuristic strategy that selects the minimum CU configuration under cost-optimization policy, and the maximum CU under performance-optimization policy. Despite its simplicity, this rule is effective for queries whose performance-resource scales approximately linearly. • ScaleSense-naive (S-naive): An ablated variant of Scale- Sense that removes the Factor-Informed Hurwicz Criterion, re- lying solely on the median (Q50) point estimate for CU selection. This baseline isolates the contribution of the uncertainty-aware decision module. Benchmark. The evaluation of ScaleSense considers both repres- entative production workloads and the open TPC-DS 1TB bench- mark. For query performance and resource estimation experiments, we evaluate on two real-world production datasets, large-scale data- set D1 and mid-scale dataset D2, both comprising complex queries with execution times exceeding 1 second, making them well-suited for estimation and on-demand scaling tasks. D1 contains 1 million real SQL queries executed across 117 distinct CU configurations. D2 is constrained to six hardware configurations (16, 32, 64, 128, 256, and 512 CUs) and contains 360K real SQL queries. For the performance and resource estimation experiments, D1 and D2 are each split into training and test sets at an 8:2 ratio for in-distribution evaluation. Since real-world on-demand scal- ing scenarios typically involve complex, out-of-distribution (OOD) queries, we adopt the open TPC-DS 1TB benchmark as the test set for auto-scaling evaluation. Specifically, we restrict the can- didate CU configurations to the same six settings (16, 32, 64, 128, 256, and 512 CUs), train all methods on D2, and evaluate their CU recommendation effectiveness on TPC-DS 1TB. Evaluation Metrics. Q-error is widely regarded as the standard metric [25], defined asmax( ˆ 푦/푦, 푦/ ˆ 푦). We report the median and 90th-percentile Q-errors for all predicted dimensions. Unless other- wise specified, ScaleSense uses Q50 and real label values to calcu- late evaluation metrics. Q-error measures prediction accuracy only. Memory under-estimation may cause OOM, while over-estimation mainly increases cost, and quantiles with FIHC handle this asym- metry. Relative Q-error is Q-error of method 푀 Q-error of best baseline , so values below 1 indicate improvement. Since ScaleSense produces quantile inter- vals, we additionally report two interval-based metrics: Coverage Rate (CR), the fraction of true values falling within the predicted interval, and Interval Width (IW), the mean width of the prediction intervals. Additionally, we evaluate the zero-inflated classifiers us- ing classification accuracy on zero-valued samples. To evaluate the effectiveness of on-demand scaling solutions, we adopt Constraint Satisfaction Accuracy (CSA) as the primary metric. CSA measures the fraction of feasible queries for which the recommended CU configuration satisfies both the performance constraint and the cost constraint simultaneously. Implementation Details. We reuse the full set of plan-level fea- tures introduced in SafeLoad [33]. ScaleSense incorporates a Plan Graph Transformer that uses 8 Laplacian eigenvectors, 2 Trans- former layers with a hidden dimension of 64, and 4 attention heads. For the plan tree summarization procedure, we set the chunk size to 200 operator nodes, a threshold empirically determined from AnalyticDB production statistics. Both the Bound Factor Predictor (Stage 1) and the Latency Predictor (Stage 2) employ XGBoost-based quantile regression with a maximum tree depth of 10, a learning rate of 0.03, and subsample and column sample ratios of 0.8. The Graph Transformer and XGBoost settings are adopted from prior work [18,33]. Although XGBoost-based quantile regressors ex- trapolate conservatively beyond the training range, ScaleSense mitigates this limitation through log-scale targets, broad produc- tion coverage, and a fallback to the maximum CU when prediction intervals become wide. 5.2 Prediction Performance Comparison (EQ1) We comprehensively evaluate ScaleSense against all baselines on five prediction targets — query latency, CPU time, peak memory size, table scan volume, and shuffle size — using the real production datasets D1 and D2. In addition, we report the performance of the quantile interval prediction unique to ScaleSense. Prediction Accuracy. As shown in Figure 8, on the large-scale production dataset D1, ScaleSense achieves the best Q-Error me- dian across all prediction targets. For Q-Error P90, which reflects tail-case prediction quality, ScaleSense attains the best results on table scan volume, shuffle size, and peak memory size. Specifically, for table scan volume, ScaleSense reduces the Q-Error median by 52.4% and the Q-Error P90 by 78.3% relative to the best baseline, demonstrating a substantial prediction advantage. For shuffle size, ScaleSense reduces the Q-Error median by 37.3% and the Q-Error P90 by 59.8% relative to the best baseline, again showing a signific- ant improvement. For peak memory size, ScaleSense improves the Figure 8: Relative Q-Error of methods compared to the best baseline (lower is better) on the real production datasets D1 and D2. Q-Error median by 8.7% over the best baseline, with a marginal in- crease in Q-Error P90. For the time-related metrics, latency and CPU time, ScaleSense maintains the best Q-Error median with modest improvements of 1.6% and 5.1% over the best baseline, respectively, while exhibiting a slight degradation in Q-Error P90. Overall, Scale- Sense achieves the best prediction performance for the majority of queries across all prediction targets on the production dataset D1. As shown in Figure 8, on the mid-scale production dataset D2, the reduced diversity of hardware configurations compared to D1 narrows the variation in extreme cases at the P90 quantile, mak- ing the advantage of ScaleSense more pronounced. ScaleSense achieves the best Q-Error median and P90 on every prediction tar- get except for the Q-Error P90 of CPU time. Specifically, for table scan volume, ScaleSense reduces the Q-Error median by 7.3% and the Q-Error P90 by 81.1% relative to the best baseline. For shuffle size, ScaleSense improves the Q-Error median by 5.6% and the Q-Error P90 by 58.1% over the best baseline. For peak memory size, ScaleSense improves the Q-Error median by 2.8% over the best baseline, while also achieving a 17.1% improvement in Q-Error P90. Efficiency of Quantile Prediction. As shown in Table 2, Scale- Sense not only provides accurate point estimates but also predicts Q10–Q90 quantile intervals as prediction bounds. Across all five dimensions on both D1 and D2, the coverage rates range from 68% to 86% with narrow interval widths, confirming that the predicted intervals reliably capture the true values. These bounds enable the Factor-Informed Hurwicz criterion to quantify resource uncertainty and make more robust CU selection decisions, which is the key advantage over point-estimate-only baselines. Zero-Inflated Classification. ScaleSense also achieves good accuracy in zero-inflated classification. For peak memory size, the classification accuracy reaches 0.94 on D1 and 0.81 on D2. For table scan volume, it attains 0.93 on D1 and 0.96 on D2. For shuffle size, the accuracy is 0.97 on D1 and 0.85 on D2. Summary. ScaleSense consistently achieves the best or near-best Q-Error median across all five prediction targets on both D1 and D2, with particularly pronounced improvements on I/O-related dimensions such as table scan volume and shuffle size. Beyond Table 2: Quantile prediction and zero-inflated classification performance of ScaleSense on D1 and D2. DatasetTargetQ-error (Median)Q-error P90Coverage RateAcc.Avg. IW D1 Latency1.252.8778.87%\5.37 s Peak Memory Size1.052.6268.03%0.940.15 GB Table Scan Volume1.003.8983.03%0.930.39 GB Shuffle Size1.012.9285.70%0.970.21 GB CPU Time1.685.6778.84%\69.95 s D2 Latency1.161.7878.13%\2.05 s Peak Memory Size1.061.5578.22%0.810.06 GB Table Scan Volume1.012.9782.85%0.960.15 GB Shuffle Size1.012.6082.25%0.850.18 GB CPU Time1.393.1977.02%\31.03 s point estimation, its quantile interval predictions achieve good coverage with narrow interval widths, confirming that ScaleSense provides accurate, uncertainty-aware resource predictions suitable for downstream scaling decisions. 5.3 Efficiency of Auto-Scaling (EQ2) We evaluate all scaling solutions on the TPC-DS 1 TB benchmark under the constraint-based formulation defined in Problem 2. For each of the 99 TPC-DS queries, each method must recommend a target CU configuration that satisfies the user-specified con- straints on both the performance scaling factor휌and the cost scaling factor휖. We give six constraint settings that cover two com- plementary policies. For Performance Optimization (PO), the baseline is 16 CUs (the minimum configuration) and the candidate targets are 32, 64, 128, 256, 512 CUs; the user demands a speedup 휌 ∈ [3.5,4.0]×while tolerating a cost increase휖 ∈ [2.5,3.0]×. For Cost Optimization (CO), the baseline is 128 CUs (a mid-range configuration) and the candidates are 16, 32, 64, 256, 512 CUs; the user demands a cost saving휖 ∈ [1.5,2.0]×while tolerating a latency degradation 휌 ∈ [1.1, 1.3]×. These ranges are chosen to reflect practical production scenarios: PO settings target compute-intensive queries that benefit from sub- stantial scale-up, while CO settings target over-provisioned queries where moderate scale-down yields significant savings with min- imal performance impact. Under the PO policy, the sum of the user-expected scaling ratios exceeds the heuristic threshold of 5, so ScaleSense assigns훼=0; under the CO policy, the user expecta- tions are more conservative, and ScaleSense accordingly assigns 훼=1. Within each policy, we progressively tighten the constraints across three settings to stress-test each method’s robustness. Performance Optimization (PO). Figure 9 reports the constraint satisfaction accuracy and the average speedup and cost ratio achieved by each method under three PO settings (baseline = 16 CUs, targets ∈32, 64, 128, 256, 512). The green and red dashed lines indicate the speedup and cost tolerance thresholds, respectively. For example, the setting (휌 ≥3.5×,휖 ≤3×) requires at least a 3.5×speedup while the cost must not exceed 3×the baseline. Across all three settings, ScaleSense achieves the highest accuracy, satisfying the user constraints on 57.1%–64.9% of feasible queries, compared to 28.6%–41.4% for the best baseline (XGB). On average, ScaleSense improves over the best baseline by 26.1 percentage points (p), corresponding to a relative improvement of 80.6%. Crucially, Scale- Sense maintains an average cost ratio within the user-specified tolerance (e.g.,휖=2.87×under a 3×budget), whereas all baselines exceed the cost constraint on average (e.g., XGB averages 4.78×), indicating that they tend to over-provision resources. All baselines achieve higher total speedups (3.6–4.4×) than ScaleSense (2.7×), but at the expense of a 4.7–7.2×cost increase, far exceeding the user budget. In contrast, ScaleSense keeps the total cost increase at 3.4–3.6×, demonstrating that it selects moderate configurations that balance speedup and cost rather than blindly maximizing per- formance. Cost Optimization (CO). Figure 10 reports the results under three CO settings (baseline = 128 CUs, targets∈16, 32, 64 CUs). For ex- ample, the setting (휖 ≥1.5×,휌 ≤1.1×) requires at least a 1.5×cost saving while the latency degradation must not exceed 1.1×. Scale- Sense achieves 64.5%–73.0% accuracy, compared to 36.5%–43.5% for the best baseline (MLP), an average improvement of 28.3 p. Not- ably, ScaleSense keeps the average latency degradation close to the tolerance bound (e.g.,휌=1.09×under a 1.1×constraint), while all baselines incur substantially higher slowdowns (e.g., MLP averages 1.83×), reflecting their inability to identify configurations that save cost without excessive performance loss. All baselines achieve a 3.1×total cost saving but incur a 2.6×total slowdown, indicating that they uniformly select the lowest CU (16) regardless of the con- straint. ScaleSense achieves a more moderate 1.8×cost saving with only 1.8–1.9×slowdown. This is precisely why the saving target is not the main discriminative factor in Figure 10: exceeding the target is easy if a method always chooses the smallest configuration, but doing so usually violates the latency constraint. The key question is whether a method can realize non-trivial savings without breaking the user-specified SLA, which is where ScaleSense differs from the baselines. Impact of the Factor-Informed Hurwicz Criterion. To isolate the contribution of the uncertainty-aware FIHC module, we com- pare ScaleSense with S-naive, an ablated variant that uses only the median (Q50) point estimate for CU selection. Under the six settings (with CO candidates restricted to 16, 32, 64), the Factor- Informed Hurwicz criterion improves CSA by an average of 27.13 p over S-naive. The gain is +24.89 p in performance-optimization settings and +29.37 p in cost-optimization settings. FIHC also out- performs two simpler static robust alternatives: relative to always using Q10 and Q90, it improves CSA by +27.71 p and +17.59 p Figure 9: Performance optimization (base CUs = 16 CUs). Figure 10: Cost optimization (base CUs = 128 CUs). on average, respectively. These results show that the controller gain does not come from choosing a single conservative or optim- istic quantile; it comes from factor-informed adaptation between quantiles according to policy semantics and resource pressure. Summary. Across all six constraint settings, ScaleSense outper- forms the best baseline by an average of 27.2 p in constraint sat- isfaction accuracy (relative improvement of 76.7%). The Factor- Informed Hurwicz criterion accounts for the majority of this gain (+27.1 p over S-naive), confirming that FIHC is the key enabler for effective on-demand scaling. Notably, under the performance- optimization policy, it satisfies user-defined performance require- ments while reducing monetary cost by up to 5.22×compared to existing methods. 5.4 Time Overheads (EQ3) We analyze the training and inference overheads of ScaleSense and all baselines. Training Overheads. On the D1 and D2 training sets compris- ing 800K and 288K queries, respectively, ScaleSense completes training in 294 s and 160 s. This is slower than XGB (26 s and 16 s) and LGBM (112 s and 85 s), but faster than MLP (585 s and 196 s) and GTN (630 s and 202 s). The training cost of ScaleSense falls between the tree-based and neural network baselines, as it employs XGBoost as the underlying model for quantile interval prediction. Nevertheless, these offline training costs are modest and remain entirely acceptable even for daily retraining scenarios. Inference Overheads. On the D1 and D2 test sets containing 200K and 72K queries, respectively, ScaleSense completes inference in approximately 4 s and 2 s. All baselines, being lightweight models, also finish within 1–4 s. In all cases, the inference overhead amounts to less than 1% of the average query execution time and is therefore negligible in practice. 6 RELATED WORK Intelligent Auto-Scaling. Existing cloud data warehouses em- ploy various workload management and scaling strategies. Snow- flake [10] leverages independent virtual warehouses for workload isolation and elastic capacity. Microsoft’s Moneyball [22] proact- ively predicts per-database pause/resume patterns to reduce resume latency after idle periods, trading off quality of service and operating cost at the database level. Regarding predictive scaling in analytical warehouses, AWS Redshift RAIS [21,28] uses proactive, predictive algorithms that learn workload patterns and query complexity to ad- just resources before degradation occurs. At a coarser provisioning granularity, Doppler [6] recommends right-sized Azure SQL PaaS targets for workload migration using low-level resource statistics and price-performance ranking, while Lorentz [12] recommends SKUs for newly provisioned services from customer profile data and continuous feedback when workload traces are unavailable. In contrast, ScaleSense introduces predictive CU resizing methodolo- gies through multidimensional resource estimation. Furthermore, ScaleSense operates at per-query granularity with uncertainty quantification, enabling finer-grained resource allocation decisions. Query Resource Estimation. Early work used kernel canonical correlation analysis for memory prediction [11]. Recent ML-based approaches include XGBoost on SQL text features [30] and CASA’s statistical feature extraction [34]. LinkedIn’s QPP study [29] evalu- ated TLSTM and TCNN on industrial OLAP workloads, extending to CPU time prediction. These methods primarily produce point estim- ates for single metrics. ScaleSense advances the state-of-the-art by: (1) predicting key performance bound factors (CPU, memory, disk, network), (2) providing calibrated prediction intervals via quantile regression to enable transferable performance bound estimation across diverse hardware configurations. Learned Query Optimization. Learned query optimization has emerged as a promising direction for improving database perform- ance. QueryFormer [37] and DACE [16] augment the Transformer architecture using height encoding and tree-structured attention masks, respectively. Lero [39] and LEON [7] employ pairwise query plan ranking rather than exact cost estimation for robust query op- timization. A comparative study [38] systematically analyzed plan encoding techniques across these methods. Learned cost models (LCMs) in this line of work focus on estimating the abstract cost of candidate query plans, whereas ScaleSense predicts hardware- dependent resource consumption and latency across candidate CU configurations. 7 LESSONS AND FUTURE DIRECTIONS This section summarizes failure analysis and operational lessons learned from building ScaleSense in an industrial serverless data warehouse, AnalyticDB. Lesson 1: Deployment-oriented analysis is essential when full replay is infeasible. In production, privacy constraints pre- vent access to the underlying customer data. As a result, we cannot replay the same user query under multiple CU configurations to obtain ground-truth labels for CU selection. Controlled benchmarks such as TPC-DS are therefore indispensable for end-to-end evalu- ation under comparable conditions. At the same time, deployment- oriented analysis of real customer workloads remains necessary to verify that the learned recommendations translate into practical value. Lesson 2: Failure analysis is useful for constructing an effect- ive feedback mechanism. Under-provisioning CUs for complex queries may cause resource exhaustion and execution failure. In our failure case study, TPC-DS 1TB query Q67 fails at 16 CUs because its large-scale shuffle and global sort operators create substantial memory pressure. This illustrates why CU selection should expli- citly model resource pressure, rather than relying on latency point estimates alone, in modules such as the Factor-Informed Hurwicz Criterion. More importantly, the system should include a dedicated failure-aware fallback mechanism. Lesson 3: Robust relative ranking matters more than absolute accuracy. Out-of-distribution robustness is more important than in-distribution accuracy: preserving the relative ranking across can- didate CU configurations, together with uncertainty-aware fallback, is sufficient to make safe and effective scaling decisions. 8 CONCLUSION In this paper, we present ScaleSense, an on-demand scaling frame- work for cloud-native serverless data warehouses that addresses the challenge of selecting appropriate CU configurations. By jointly pre- dicting query latency and multi-dimensional resource consumption with quantile uncertainty estimates, ScaleSense explicitly models the performance–cost trade-off and translates it into actionable scal- ing decisions aligned with user-defined preferences. Experimental evaluation demonstrates that ScaleSense achieves state-of-the-art constraint-satisfaction accuracy in CU recommendation. ACKNOWLEDGMENTS This research is supported by the NSFC under Grants No. U24A201401 and No. 62402420, and also supported by CCF-Aliyun Apsara Re- search Fund (No. CCF-Aliyun2024008). We thank the anonymous reviewers and the AnalyticDB team for their valuable feedback and suggestions. REFERENCES [1]Alibaba Cloud. 2026. AnalyticDB Compute Unit (ACU) Terms and Defin- itions. https://help.aliyun.com/en/analyticdb/analyticdb-for-mysql/product- overview/terms. Accessed: 2026-03-02. [2]Omid Alipourfard, Hongqiang Harry Liu, Jianshu Chen, Shivaram Venkataraman, Minlan Yu, and Ming Zhang. 2017. Cherrypick: adaptively unearthing the best cloud configurations for big data analytics. In Proceedings of the 14th USENIX Conference on Networked Systems Design and Implementation (Boston, MA, USA) (NSDI’17). USENIX Association, USA, 469–482. [3]Amazon Web Services. 2026. Amazon Redshift Serverless Capacity and RPUs. https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-capacity.html. Ac- cessed: 2026-03-02. [4] Nikos Armenatzoglou, Sanuj Basu, Naga Bhanoori, Mengchu Cai, Naresh Chain- ani, Kiran Chinta, Venkatraman Govindaraju, Todd J. Green, Monish Gupta, Sebastian Hillig, Eric Hotinger, Yan Leshinksy, Jintian Liang, Michael McCreedy, Fabian Nagel, Ippokratis Pandis, Panos Parchas, Rahul Pathak, Orestis Poly- chroniou, Foyzur Rahman, Gaurav Saxena, Gokul Soundararajan, Sriram Sub- ramanian, and Doug Terry. 2022. Amazon Redshift Re-invented. In Proceedings of the 2022 International Conference on Management of Data (Philadelphia, PA, USA) (SIGMOD ’22). Association for Computing Machinery, New York, NY, USA, 2205–2217. [5] The SafeLoad authors. 2025. The SafeBench Benchmark. https://github.com/ SafeLoad-project/SafeBench. Accessed: 2026-03-02. [6]Joyce Cahoon, Wenjing Wang, Yiwen Zhu, Katherine Lin, Sean Liu, Raymond Truong, Neetu Singh, Chengcheng Wan, Alexandra Ciortea, Sreraman Narasim- han, and Subru Krishnan. 2022. Doppler: automated SKU recommendation in migrating SQL workloads to the cloud. Proc. VLDB Endow. 15, 12 (Aug. 2022), 3509–3521. [7]Xu Chen, Haitian Chen, Zibo Liang, Shuncheng Liu, Jinghong Wang, Kai Zeng, Han Su, and Kai Zheng. 2023. LEON: A New Framework for ML-Aided Query Optimization. Proc. VLDB Endow. 16, 9 (May 2023), 2261–2273. [8]Alibaba Cloud. 2026. AnalyticDB for MySQL. https://w.alibabacloud.com/ product/analyticdb-for-mysql. [9]Eli Cortez, Anand Bonde, Benjamin Muzio, Mark Russinovich, Marcus Fontoura, and Ricardo Bianchini. 2017. Resource Central: Understanding and Predicting Workload Resources in the Cloud. In Proceedings of the 26th Symposium on Operating Systems Principles (SOSP). 153–167. [10]Benoit Dageville, Thierry Cruanes, Marcin Zukowski, Vadim Antonov, Artin Avanes, Jon Bock, Jonathan Claybaugh, Daniel Engovatov, Martin Hentschel, Jiansheng Huang, Allison W. Lee, Ashish Motivala, Abdul Q. Munir, Steven Pelley, Peter Povinec, Greg Rahn, Spyridon Triantafyllis, and Philipp Unterbrunner. 2016. The Snowflake Elastic Data Warehouse. In Proceedings of the 2016 International Conference on Management of Data (San Francisco, California, USA) (SIGMOD ’16). Association for Computing Machinery, New York, NY, USA, 215–226. https: //doi.org/10.1145/2882903.2903741 [11] Archana Ganapathi, Harumi A. Kuno, Umeshwar Dayal, Janet L. Wiener, Ar- mando Fox, Michael I. Jordan, and David A. Patterson. 2009. Predicting Multiple Metrics for Queries: Better Decisions Enabled by Machine Learning. In Proceed- ings of the 25th International Conference on Data Engineering, ICDE 2009, March 29 2009 - April 2 2009, Shanghai, China. 592–603. [12]Nick Glaze, Tria McNeely, Yiwen Zhu, Matthew Gleeson, Helen Serr, Rajeev Bhopi, and Subru Krishnan. 2024. Lorentz: Learned SKU Recommendation Using Profile Data. Proc. ACM Manag. Data 2, 3, Article 149 (May 2024), 25 pages. [13]Sven Helmer, Peter Wood, and Manuel Stuefer. 2025. Using the Hurwicz Criterion to Optimize Selection Queries Under Partial Ignorance. International Journal of Semantic Computing 19 (05 2025), 197–221. [14]Leonid Hurwicz. 1951. Optimality Criteria for Decision Making Under Ignorance. Discussion Paper: Statistics 370. Cowles Commission for Research in Economics. [15]Zhao Lucis Li, Chieh-Jan Mike Liang, Wenjia He, Lianjie Zhu, Wenjun Dai, Jin Jiang, and Guangzhong Sun. 2018. Metis: robustly optimizing tail latencies of cloud systems. In Proceedings of the 2018 USENIX Conference on Usenix Annual Technical Conference (Boston, MA, USA) (USENIX ATC ’18). USENIX Association, USA, 981–992. [16]Zibo Liang, Xu Chen, Yuyang Xia, Runfan Ye, Haitian Chen, Jiandong Xie, and Kai Zheng. 2024. DACE: A database-agnostic cost estimator. In 40th IEEE International Conference on Data Engineering, ICDE 2024, Utrecht, The Netherlands, May 13-16, 2024. 4925–4937. [17]Chenghao Lyu, Qi Fan, Philippe Guyard, and Yanlei Diao. 2024. A Spark Optim- izer for Adaptive, Fine-Grained Parameter Tuning. Proc. VLDB Endow. 17, 11 (July 2024), 3565–3579. [18]Chenghao Lyu, Guillaume Lachaud, Gabriel Lozano, and Yanlei Diao. 2026. Graph Transformers for Query Plan Representation: Potentials and Challenges. Proc. VLDB Endow. 18, 13 (Jan. 2026), 5716–5730. [19]Ryan Marcus, Parimarjan Negi, Hongzi Mao, Nesime Tatbul, Mohammad Aliza- deh, and Tim Kraska. 2022. Bao: Making Learned Query Optimization Practical. SIGMOD Rec. 51, 1 (June 2022), 6–13. [20]Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shiv- akumar, Matt Tolton, Theo Vassilakis, Hossein Ahmadi, Dan Delorey, Slava Min, Mosha Pasumansky, and Jeff Shute. 2020. Dremel: a decade of interactive SQL analysis at web scale. Proc. VLDB Endow. 13, 12 (Aug. 2020), 3461–3472. https://doi.org/10.14778/3415478.3415568 [21] Vikram Nathan, Vikramank Singh, Zhengchun Liu, Mohammad Rahman, An- dreas Kipf, Dominik Horn, Davide Pagano, Gaurav Saxena, Balakrishnan Naray- anaswamy, and Tim Kraska. 2024. Intelligent Scaling in Amazon Redshift. In Companion of the 2024 International Conference on Management of Data (Santiago A, Chile) (SIGMOD ’24). Association for Computing Machinery, New York, NY, USA, 269–279. [22]Olga Poppe, Qun Guo, Willis Lang, Pankaj Arora, Morgan Oslake, Shize Xu, and Ajay Kalhan. 2022. Moneyball: proactive auto-scaling in Microsoft Azure SQL database serverless. Proc. VLDB Endow. 15, 6 (Feb. 2022), 1279–1287. [23] Chenhao Qu, Rodrigo N. Calheiros, and Rajkumar Buyya. 2018. Auto-Scaling Web Applications in Clouds: A Taxonomy and Survey. ACM Comput. Surv. 51, 4, Article 73 (July 2018), 33 pages. https://doi.org/10.1145/3148149 [24] Shaikh Quader, Andres Jaramillo, Sumona Mukhopadhyay, Ghadeer Abuoda, Cal- isto Zuzarte, David Kalmuk, Marin Litoiu, and Manos Papagelis. 2024. Learned- WMP: Workload Memory Prediction Using Distribution of Query Templates. CoRR abs/2401.12103 (2024). arXiv:2401.12103 [25]Maximilian Rieger and Thomas Neumann. 2025. T3: Accurate and Fast Perform- ance Prediction for Relational Database Systems With Compiled Decision Trees. Proc. ACM Manag. Data 3, 3, Article 227 (June 2025), 27 pages. [26]Yaniv Romano, Evan Patterson, and Emmanuel J. Candès. 2019. Conformalized quantile regression. Curran Associates Inc., Red Hook, NY, USA. [27]Krzysztof Rzadca, Pawel Findeisen, Jacek Swiderski, Przemyslaw Zych, Przemyslaw Broniek, Jacek Kusmierek, Pawel Gorczyk, Xiao Liu, Gregory Wig- gers, Itai Magid, et al.2020. Autopilot: workload autoscaling at Google. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. 1357–1367. [28]Amazon Web Services. 2026.Amazon Redshift Workload Manage- ment. https://docs.aws.amazon.com/redshift/latest/dg/c_workload_mngmt_ classification.html. [29]Chujun Song, Slim Bouguerra, Erik Krogen, and Daniel Abadi. 2025. Evalu- ating Learned Query Performance Prediction Models at LinkedIn: Challenges, Opportunities, and Findings. CoRR abs/2504.17181 (2025). [30]Chunxu Tang, Beinan Wang, Zhenxiao Luo, Huijun Wu, Shajan Dasan, Maosong Fu, Yao Li, Mainak Ghosh, Ruchin Kabra, Nikhil Kantibhai Navadiya, Da Cheng, Fred Dai, Vrushali Channapattan, and Prachi Mishra. 2021. Forecasting SQL Query Cost at Twitter. In IEEE International Conference on Cloud Engineering, IC2E 2021, San Francisco, CA, USA, October 4-8, 2021. 154–160. [31] AnalyticDB Team. 2026. AnalyticDB: Pricing Plans. https://w.alibabacloud. com/help/en/analyticdb/analyticdb-for-mysql/product-overview/billing- overview. Accessed: 2026-05-11. [32] Immanuel Trummer, Junxiong Wang, Ziyun Wei, Deepak Maram, Samuel Mose- ley, Saehan Jo, Joseph Antonakakis, and Ankush Rayabhari. 2021. SkinnerDB: Regret-bounded Query Evaluation via Reinforcement Learning. ACM Trans. Database Syst. 46, 3, Article 9 (Sept. 2021), 45 pages. [33] Yifan Wu, Yuhan Li, Zhenhua Wang, Zhongle Xie, Dingyu Yang, Ke Chen, Lidan Shou, Bo Tang, Liang Lin, Huan Li, and Gang Chen. 2025. SafeLoad: Efficient Admission Control Framework for Identifying Memory-Overloading Queries in Cloud Data Warehouses. Proc. VLDB Endow. 19, 4 (Dec. 2025), 713–725. [34]Tim Zeyl, Harshwin Venugopal, Calvin Sun, and Paul Larson. 2024. CASA: Classification-based Adjusted Slot Admission Control for Query Processing Engines. In 40th International Conference on Data Engineering, ICDE 2024 - Work- shops, Utrecht, Netherlands, May 13-16, 2024. 278–284. [35]Huanchen Zhang, Yihao Liu, and Jiaqi Yan. 2023. Cost-Intelligent Data Analytics in the Cloud. arXiv:2308.09569 [cs.DB] https://arxiv.org/abs/2308.09569 [36] Zhuo Zhang, Chao Li, Yangyu Tao, Renyu Yang, Hong Tang, and Jie Xu. 2014. Fuxi: a fault-tolerant resource management and job scheduling system at internet scale. Proc. VLDB Endow. 7, 13 (Aug. 2014), 1393–1404. https://doi.org/10.14778/ 2733004.2733012 [37]Yue Zhao, Gao Cong, Jiachen Shi, and Chunyan Miao. 2022. QueryFormer: a tree transformer model for query plan representation. Proc. VLDB Endow. 15, 8 (April 2022), 1658–1670. [38] Yue Zhao, Zhaodonghui Li, and Gao Cong. 2023. A Comparative Study and Com- ponent Analysis of Query Plan Representation Techniques in ML4DB Studies. Proc. VLDB Endow. 17, 4 (Dec. 2023), 823–835. [39]Rong Zhu, Wei Chen, Bolin Ding, Xingguang Chen, Andreas Pfadler, Ziniu Wu, and Jingren Zhou. 2023. Lero: A Learning-to-Rank Query Optimizer. Proc. VLDB Endow. 16, 6 (Feb. 2023), 1466–1479.