Learned Cost Models (LCMs)

• Learned Cost Models (LCMs) are machine learning predictors that estimate runtime from structured descriptions of query plans, using supervised training on executed queries.
• They employ structured representations like plan trees and heterogeneous graphs to capture operator semantics, making them applicable across database, stream processing, and hardware mapping.
• LCMs improve cost estimation accuracy compared to hand-crafted formulas, facilitating enhanced query routing, optimization, and hybrid decision-making in complex systems.

Searching arXiv for papers on learned cost models and related systems. Learned Cost Models (LCMs) are learned predictors used to estimate execution cost from structured descriptions of candidate computations, most often query plans, plan graphs, or placement graphs. In database systems, the dominant target is runtime or execution time rather than a symbolic optimizer score, and the main motivation is that hand-crafted cost formulas rely on simplifying assumptions that can badly misestimate performance. The same design pattern now appears in cross-engine SQL routing, UDF-aware optimization, distributed stream processing, compiler placement on reconfigurable hardware, unit-commitment screening, and symbolic planning, although the learned quantity and the integration point vary substantially across domains (Hilprecht et al., 2022, Strausz et al., 3 Jun 2025, Wehrstein et al., 31 Mar 2025, Heinrich et al., 2024, Guha et al., 21 Oct 2025, He et al., 2022, Morales et al., 2024).

1. Definition, boundaries, and problem settings

In the contemporary database literature, an LCM is typically a supervised model trained on executed plans or queries to predict runtime for new plans. The zero-shot database line formulates the problem as physical query cost estimation from featurized plans and database statistics, with runtimes as labels; the cross-engine line extends the target to a vector of execution times over multiple engines and provisionings; and explainability work treats the output as a scalar runtime prediction whose internal dependencies should be inspectable at plan-node level (Hilprecht et al., 2022, Strausz et al., 3 Jun 2025, Heinrich et al., 19 Jul 2025).

Beyond single-engine relational optimization, closely related systems broaden both the target and the operational setting. COSTREAM predicts a vector $C=(T,L_p,L_e,R_O,S)$ for operator placement in edge-cloud stream processing, where throughput and latencies are regression targets while backpressure occurrence and query success are binary targets (Heinrich et al., 2024). A compiler LCM for reconfigurable dataflow hardware predicts normalized throughput of a placement-and-routing decision and uses that prediction inside a simulated-annealing-style placer (Guha et al., 21 Oct 2025). In unit commitment, the learned quantity is the optimal UC cost $J(\boldsymbol{\ell})$ as a function of load, and the model is used to tighten a downstream constraint-screening LP rather than to replace the optimizer itself (He et al., 2022). In symbolic planning, the learned object is a shared action-cost function over a STRIPS action set such that observed plans become optimal under the induced planning model (Li et al., 2024).

The term also has boundaries. CARMI is explicitly not a learned cost model in the modern sense of a predictive ML model trained to estimate cost; it is a cost-based optimizer for learned indexes built around a mostly handcrafted analytical model with entropy as a partition-quality metric (Zhang et al., 2021). That contrast is useful because it shows that the LCM label is most precise when the central mechanism is learned prediction of runtime, throughput, or objective value from features, rather than analytical scoring alone.

Setting	Learned quantity	Decision role
Zero-shot database cost estimation	Query runtime (Hilprecht et al., 2022)	Cost prediction on unseen databases
Cross-engine lakehouse optimization	Per-engine execution time (Strausz et al., 3 Jun 2025)	Engine/provisioning routing
UDF-aware database optimization	Runtime of SQL queries with UDFs (Wehrstein et al., 31 Mar 2025)	UDF pull-up/push-down decisions
Edge-cloud stream processing	$T,L_p,L_e,R_O,S$ (Heinrich et al., 2024)	Initial operator placement
Reconfigurable dataflow compilation	Normalized throughput (Guha et al., 21 Oct 2025)	Placement scoring in compiler search
Unit commitment screening	$J(\boldsymbol{\ell})$ (He et al., 2022)	Cost cap for LP screening
Classical planning	Shared action costs (Li et al., 2024)	Make observed plans optimal

2. Representations and model architectures

A recurrent property of LCM research is that the input is rarely flat SQL text alone. Recent models favor plan-aware trees or heterogeneous graphs that encode operator semantics, cardinality context, and sometimes resource structure. The zero-shot representation of Hilprecht et al. models physical plan operators together with predicates, tables, attributes, and output columns in a multi-typed graph; the explainability paper later emphasizes that graph-based LCMs such as the Zero-Shot cost model encode a query as a graph containing physical operators as well as additional nodes for predicates, join conditions, tables, and columns, and that explanations should therefore be produced over the actual graph input rather than a simplified tree (Hilprecht et al., 2022, Heinrich et al., 19 Jul 2025).

Cross-engine SQL optimization adopts a heterogeneous graph derived from an optimized Substrait plan with five node types—Relation, Operation, Literal, Field, and Table—and processes it with a Bottom-up GNN. Each node type has a type-specific encoder MLP, message passing proceeds bottom-up, and the final query embedding is formed by mean pooling over Relation-node embeddings before multiple engine-specific predictor heads estimate runtimes (Strausz et al., 3 Jun 2025). Delta instead uses a plan-tree representation: each node carries a one-hot operator encoding, min-max normalized cardinality estimate, min-max normalized cost estimate, and a one-hot encoding sum of the relations involved in the rooted subplan. A tree-convolutional model with dynamic pooling then feeds dual heads that predict latency and heteroscedastic noise for Stage II plan selection (Peng et al., 18 Jun 2025).

When the plan contains opaque program code, the representation grows accordingly. GRACEFUL constructs a joint graph from the query plan and a UDF control-flow graph transformed into a DAG, with UDF node types INV, COMP, BRANCH, LOOP/LOOP_END, and RET. It also adds explicit links from query COLUMN nodes into the UDF and from the UDF RET node back to downstream plan nodes, so the learned estimator sees both relational context and UDF internal structure (Wehrstein et al., 31 Mar 2025).

Placement-oriented LCMs extend the same principle to computation-plus-resource graphs. COSTREAM represents a streaming query as a joint graph containing operator nodes, hardware nodes, logical data-flow edges, and placement edges. Its message-passing order is deliberately asymmetric—operators $\rightarrow$ hardware, hardware $\rightarrow$ operators, and sources $\rightarrow$ operators—to reflect contention, host capability, and workload propagation (Heinrich et al., 2024). The compiler LCM for reconfigurable dataflow hardware likewise represents a candidate mapping as a graph $G=(V,E)$ where nodes are actively used functional units and edges are used routes, with node embeddings $X_v=[X_v^F,X_{O(v)}^O,X_{S(v)}^S]$ and route-aware edge embeddings processed by a GNN plus a 3-layer ReLU MLP regressor (Guha et al., 21 Oct 2025).

This suggests a broad structural pattern: LCMs are usually most effective when the representation mirrors the combinatorial object that the optimizer actually manipulates—plan trees, heterogeneous query graphs, query-plus-code graphs, or placed hardware graphs—rather than a database-agnostic bag of features.

3. Training regimes and data construction

The original learned database cost models were largely workload-driven: they required target-database executions and therefore high onboarding cost. Zero-shot cost models replace that regime with cross-database pre-training. In the zero-shot database benchmark, the model is trained over 20 databases with 15,000 queries per database and then applied to an unseen database without target-database runtime labels; few-shot fine-tuning with a small number of target queries further improves accuracy (Hilprecht et al., 2022). Cross-engine lakehouse optimization keeps the same transfer logic at engine level: the shared Bottom-up GNN is trained on five datasets with 5,000 generated queries per dataset, and few-shot adaptation or new-engine addition is done by updating only the predictor heads with 250 queries while keeping the shared embedding fixed (Strausz et al., 3 Jun 2025).

A parallel line addresses the data bottleneck directly. The synthetic SQL bootstrapping work does not propose a new LCM architecture; it proposes a schema-specific SQL generation pipeline derived from DiGiT and inspired by self-instruct-style data generation. The pipeline creates connected subschemas, constructs few-shot prompts from CREATE statements and mechanically generated seed queries, validates generated SQL for syntax and relevance, analyzes coverage with Apache Calcite, and regenerates to fill gaps. For the downstream multi-head GNN-based LCM, training on 2,200 SDG-generated queries instead of 4,000 mechanically generated queries improves $qmedian$ from 1.20 to 1.18, $J(\boldsymbol{\ell})$0 from 1.41 to 1.34, and $J(\boldsymbol{\ell})$1 from 2.38 to 2.37, while reducing training queries by 45% (Nidd et al., 27 Aug 2025).

Other systems reuse optimization traces already produced upstream. Delta trains its Stage II cost model on the executed plan pool accumulated during Stage I value-network training, then augments that pool by extracting subplans and their direct runtimes. This expands the data by 8–9× more unique training samples on JOB and 2.5–4× on TPC-DS and Stack, which is one reason the paper characterizes Stage II training cost as negligible relative to value-network training (Peng et al., 18 Jun 2025). GRACEFUL creates a dedicated benchmark for UDF-aware costing with 93.8k queries, 20 databases, and 142 hours of benchmark runtime; COSTREAM builds a benchmark of 43,281 query traces by executing streaming queries on heterogeneous hardware; and CLEO exploits recurring production workloads across 0.5 million jobs over four clusters to train about 25K specialized models in less than 45 minutes on a 200-node cluster (Wehrstein et al., 31 Mar 2025, Heinrich et al., 2024, Siddiqui et al., 2020).

The resulting lesson is data-centric. Several papers state, directly or indirectly, that LCM quality is constrained not only by architecture but by workload representativeness, coverage of bad as well as good alternatives, and the availability of labels that match the eventual optimization task.

4. Roles inside optimizers and execution systems

LCMs are used at very different points in decision pipelines. In cross-engine lakehouse systems, the role is direct routing: estimate execution time for each engine/provisioning in $J(\boldsymbol{\ell})$2 and choose the one with minimum predicted runtime (Strausz et al., 3 Jun 2025). In Delta, the role is narrower and explicitly second-stage: a value network performs Stage I beam search over partial plans to generate $J(\boldsymbol{\ell})$3 complete candidates, and the learned cost model reranks those candidates in Stage II by predicted latency. A Mahalanobis-distance-based compatible query detector decides whether the learned planner should be trusted at all, routing incompatible queries to a fallback optimizer (Peng et al., 18 Jun 2025).

Production optimizer integration can be deeper. CLEO inserts learned exclusive-operator costing into the Cascades-style SCOPE optimizer at the Optimize Inputs stage, preserving the existing search architecture while replacing heuristic local cost estimation. It also extends the optimizer with resource-context, partition-exploration, and partition-optimization so that learned costs guide not only physical plan choice but also the number of partitions, hence the number of containers, during planning (Siddiqui et al., 2020). GRACEFUL augments a DBMS optimizer for plans with scalar Python UDFs: it enumerates pull-up and push-down alternatives for a UDF filter, varies assumed UDF-filter selectivity over $J(\boldsymbol{\ell})$4, adjusts operator cardinalities above the UDF filter accordingly, and uses predicted plan runtimes under heuristics such as UBC, AuC, and Conservative to choose a placement. In evaluation, informed pull-up/push-down decisions can yield up to 50× speedups over the standard case where filter push-down is always applied (Wehrstein et al., 31 Mar 2025).

Placement problems use LCMs as surrogate objectives. COSTREAM evaluates candidate placements of streaming operators onto heterogeneous edge-cloud hardware, filters candidates predicted to fail or exhibit backpressure, and then selects the placement that optimizes a target metric such as throughput or processing latency (Heinrich et al., 2024). The hardware-mapping model for reconfigurable dataflow compilation replaces a hand-designed throughput heuristic in a simulated-annealing placer with a learned throughput predictor over mapped graphs; this yields 5.6% faster compiled graphs in the abstract’s summary and 5.7% higher throughput on BERT-large in the body (Guha et al., 21 Oct 2025).

Some systems use learned cost information more indirectly. In unit commitment, the neural network $J(\boldsymbol{\ell})$5 predicts the optimal cost $J(\boldsymbol{\ell})$6 from load and contributes only a scalar upper bound $J(\boldsymbol{\ell})$7 or $J(\boldsymbol{\ell})$8 to a screening LP, thereby shrinking the feasible region without replacing the final optimization (He et al., 2022). In cost-aware LLM orchestration, xRouter is explicitly relevant but structurally different: it does not train a standalone supervised cost regressor, but a routing policy under the reward $J(\boldsymbol{\ell})$9, so its learned object is a cost-sensitive orchestration policy rather than an explicit cost predictor (Qian et al., 9 Oct 2025).

5. Evaluation criteria, empirical limits, and controversy

LCM papers use several families of metrics, and they do not all measure the same property. Database runtime prediction papers predominantly report Q-error summaries such as $T,L_p,L_e,R_O,S$0, $T,L_p,L_e,R_O,S$1, and $T,L_p,L_e,R_O,S$2; zero-shot cost estimation, cross-engine routing, and synthetic-SQL bootstrapping all use these measures, with the standard interpretation that a median Q-error of 1.20 means half the predictions deviate by no more than 20% multiplicatively from the true runtime (Hilprecht et al., 2022, Strausz et al., 3 Jun 2025, Nidd et al., 27 Aug 2025). Delta supplements latency regression with workload-level metrics such as WRL and GMRL, while the hardware-mapping paper emphasizes relative error and Spearman rank correlation because ranking candidate placements is central inside simulated annealing (Peng et al., 18 Jun 2025, Guha et al., 21 Oct 2025). CLEO evaluates prediction error and Pearson correlation, but also downstream latency and total processing time after actual re-optimization (Siddiqui et al., 2020).

A central controversy in the field is that better point prediction does not automatically imply better optimizer decisions. The systematic study of seven state-of-the-art LCMs across join ordering, access path selection, and physical operator selection finds that the traditional PostgreSQL cost model often still outperforms LCMs in these tasks, even though LCMs typically achieve better raw prediction accuracy on held-out plans (Heinrich et al., 3 Feb 2025). The paper’s explanation is multi-part: query optimization is a ranking-and-selection problem over candidate plans, not a single-plan regression problem; large underestimates on bad plans can create catastrophic false minima; training data is biased toward pre-optimized plans and truncated by timeouts; and some representations, notably MSCN-style SQL encodings, cannot even distinguish physical alternatives relevant to the decision. The same study also shows that hybrid models such as DACE and QPP-Net benefit strongly from using PostgreSQL cost as an input, which leads to the recommendation that future LCMs should build on expert cost signals rather than discard them outright (Heinrich et al., 3 Feb 2025).

Other empirical limits recur across domains. Zero-shot cost models depend on target-database statistics and benefit strongly from accurate cardinality estimates, with DeepDB outperforming optimizer cardinalities though the latter remain usable (Hilprecht et al., 2022). GRACEFUL’s UDF-aware estimator is highly accurate with actual or high-quality estimated cardinalities but deteriorates sharply with DuckDB optimizer cardinalities, showing that UDF runtime modeling is still bottlenecked by CE quality (Wehrstein et al., 31 Mar 2025). COSTREAM generalizes well to unseen placements, queries, and many hardware configurations, but extrapolation to unseen high network latencies is notably weaker than CPU or RAM extrapolation (Heinrich et al., 2024). The synthetic SQL bootstrapping paper is explicit about synthetic-to-real distribution shift: schema-specific and validator-controlled SQL improves training efficiency, but synthetic workloads may still miss application semantics or temporal workload patterns (Nidd et al., 27 Aug 2025).

This body of evidence suggests that the central empirical question for LCMs is not merely “how low is median Q-error,” but “under what data regime, representation, and optimizer interface does the learned model preserve the rankings that matter for actual decisions.”

6. Explainability, debugging, and open directions

As LCMs moved toward deep GNNs and tree models, a new problem emerged: accurate average predictions coexisted with large tail errors and little diagnostic visibility. “Opening The Black-Box: Explaining Learned Cost Models For Databases” presents the first approach focused specifically on explaining LCM predictions, with a local post-hoc notion of node importance over plan-graph nodes (Heinrich et al., 19 Jul 2025). The paper adapts SensitivityAnalysis and GuidedBackprop from gradient-based XAI, GNNExplainer from graph classification to regression, and introduces DiffMask, where one node is masked, the prediction is recomputed, and importance is derived from the prediction difference. Because deleting nodes would invalidate the Zero-Shot graph structure, masking is implemented by zeroing the hidden state of the corresponding node rather than removing the node outright (Heinrich et al., 19 Jul 2025).

The explainability layer also introduces database-specific diagnostics. Node Ranking sorts nodes by decreasing importance; Runtime Correlation compares normalized runtime fractions to normalized importance fractions, with subplan runtimes subtracted to isolate local operator contribution; and Explanation Quality adapts Fidelity+, Fidelity-, and CharacterizationScore to regression, scaling all metrics to $T,L_p,L_e,R_O,S$3 (Heinrich et al., 19 Jul 2025). In the demo, the interface shows SQL text, graph representation, predicted runtime, actual runtime, Q-error, and colorized node views for either importance or actual runtimes across workloads such as IMDB, TPC-H, Baseball, and synthetic workloads (Heinrich et al., 19 Jul 2025).

The empirical findings from explainability are themselves substantive. The authors often observe high correlation between node importance and actual runtimes, which suggests the explanations capture meaningful internal behavior, but they also observe cases where predictions are accurate even though the importance pattern does not match actual runtimes. Their interpretation is that a model can be right for the wrong reasons, and such mismatches should still be corrected for robust generalization. A recurring pattern is that aggregation nodes are often assigned high importance despite not accounting for much actual runtime, suggesting operator-specific blind spots or feature imbalance in the model (Heinrich et al., 19 Jul 2025).

Several future directions follow directly from the current literature. Delta argues that LCMs are most effective as accurate second-stage rerankers over a narrowed candidate set rather than as the sole search mechanism over an $T,L_p,L_e,R_O,S$4 plan space, which points toward increasingly hybrid planners (Peng et al., 18 Jun 2025). The cross-engine optimizer suggests extending from query-level runtime prediction toward node-level costs and distributed execution optimizers (Strausz et al., 3 Jun 2025). COSTREAM explicitly mentions operator reordering and degree-of-parallelism selection as extensions beyond initial placement (Heinrich et al., 2024). Zero-shot cost modeling frames few-shot adaptation as a practical remedy for workload drift and unseen join patterns (Hilprecht et al., 2022). Explainability work identifies feature importance and subgraph importance as next steps beyond node importance (Heinrich et al., 19 Jul 2025). A plausible implication is that future LCM research will be defined less by a single architecture and more by the joint treatment of transfer, hybridization, uncertainty, decision-aware evaluation, and debuggability.