Pith. sign in

REVIEW 3 major objections 5 minor 3 cited by

The paper claims that a single SQL-inspired query can define a complete predictive task and automatically produce leak-free training labels from a relational database.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · deepseek-v4-flash

2026-08-03 02:44 UTC pith:T2RUD2WD

load-bearing objection PQL is a well-designed, genuinely useful DSL for declarative training-label generation, but its claim of native leakage prevention is undercut by a grammar that allows future-referencing entity filters. the 3 major comments →

arxiv 2602.09572 v3 pith:T2RUD2WD submitted 2026-02-10 cs.DB cs.AIcs.LG

Predictive Query Language: A Domain-Specific Language for Predictive Modeling on Relational Databases

classification cs.DB cs.AIcs.LG
keywords Predictive Query Languagedeclarative machine learningtraining label generationrelational databasestemporal data leakageanchor timestamptask inferencelink prediction
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces PQL, an SQL-inspired declarative language that lets a user specify an entire predictive machine-learning task in one query. The system automatically generates a training table of entities, targets, and anchor timestamps, with temporal semantics built into the language: aggregations are computed over well-defined future windows while features are implicitly restricted to the past, preventing data leakage by construction. PQL also infers the task type and required metadata from the query structure, so regression, classification, forecasting, and recommendation tasks are handled without manual label engineering. Two implementations are presented: one for large-scale batch label generation and one for low-latency, interactive contexts such as context windows for pre-trained relational models, with reported speedups of up to 40× over baseline approaches. The paper argues that this removes a major manual bottleneck in machine learning on relational data and demonstrates it on real-world use cases including fraud detection, recommendations, and workload prediction.

Core claim

PQL decomposes any predictive task into a PREDICT target expression and a FOR EACH entity definition, with optional WHERE and ASSUMING clauses. Targets are expressed as time-windowed aggregations (SUM, COUNT, LIST_DISTINCT, etc.) relative to an anchor timestamp, and the system generates a training table whose rows are (entity, target, anchor time) triples. This design makes the prediction timeframe explicit, lets the engine infer the task type and required metadata (for example, sources of valid negative examples for link prediction), and allows training labels to be computed for arbitrary historical anchor times without temporal overlap leakage. The language is demonstrated on databases wit

What carries the argument

The central object is the PQL query grammar itself: PREDICT ... FOR EACH ... WHERE ... ASSUMING, combined with time-windowed aggregations anchored to a timestamp. The load-bearing mechanism is the anchor timestamp: every label is computed from a well-defined future interval, and every feature is implicitly restricted to the past, making leakage prevention a language-level guarantee rather than a user responsibility. The compiler pipeline—grammar parsing, AST validation, logical plan construction, and backend translation—carries each query from statement to executable plan on both batch and interactive backends.

Load-bearing premise

The database must be cleanly timestamped and immutable in history: every table has clearly defined primary and foreign keys and timestamp columns, records are inserted with correct times, and past values are never retroactively changed without a timestamped audit trail; if these fail, the leakage-free training labels the paper promises are not guaranteed.

What would settle it

Construct a small database, run a temporal PQL query to generate labels for several anchor times, then delete or backdate a transaction that occurred after one anchor time and check whether the already-generated training table for that anchor changes. If the labels shift, the engine has incorporated post-anchor information, disproving the leakage-free claim.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • A complete predictive task can be declared in a single query, collapsing the manual pipeline of entity selection, label computation, and split construction into one step.
  • Because temporal semantics are part of the query, training labels are leak-free by construction when the schema assumptions hold, eliminating a subtle and hard-to-detect class of model evaluation errors.
  • Task type and metadata are inferred automatically, enabling automated model selection and task-specific handling such as negative sampling for recommendation tasks.
  • The same query language scales from large batch label generation to sub-second interactive contexts, with reported speedups of up to 40× over baseline implementations.
  • The ASSUMING clause lets practitioners condition training on future or counterfactual events, enabling comparisons that estimate the impact of an intervention.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If clean timestamped schemas become standard practice, PQL-style queries could become the generic interface for generating training data across relational machine learning, much as SQL became the standard for data access.
  • The ASSUMING mechanism could be extended into a general counterfactual querying tool, allowing systematic estimation of treatment effects directly from historical database states.
  • The language's reliance on clean schemas suggests a natural companion: automated data-quality checks that verify timestamp integrity before training-table generation.
  • One can test the leakage-free claim directly by mutating historical rows after label generation and checking whether the generated labels change; this would make the guarantee falsifiable in practice.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper introduces PQL, an SQL-inspired declarative language for specifying predictive tasks on relational databases. A PQL query combines a PREDICT target (column, aggregation, or condition over temporal aggregations), a FOR EACH entity definition with WHERE filters, and an optional ASSUMING future-looking filter. The authors claim that a single query can automatically generate training labels for regression, classification, time-series forecasting, recommender systems, and related tasks, while natively enforcing temporal semantics and preventing leakage. The paper presents the grammar in Figure 6, discusses task inference, anchor-time sampling, and two implementations: a Spark-based batch implementation for Relational Deep Learning and a low-latency implementation for a Relational Foundation Model. Experiments report speedups in both regimes, and the paper describes several production use cases.

Significance. The problem addressed is real and practically important: training-table construction for relational ML is manual, slow, and error-prone. A well-designed declarative language could be a significant contribution, and the manuscript contains several strengths: the grammar is stated precisely in ANTLR form; the semantic intent of temporal offsets is clear; the ASSUMING clause is a thoughtful device for counterfactual-style training conditioning; and the two implementations cover genuinely different deployment regimes. The benchmark results, while limited, indicate that the approach can be made efficient. However, the central leakage-free claim is currently not enforced by the language as specified, and the evaluation does not check that generated labels are correct. These issues are fixable, and if addressed the paper could be an important systems/data-management contribution.

major comments (3)
  1. [Section 3.3, Figure 6; Sections 1 and 3.7] The grammar permits future-referencing temporal aggregations in the WHERE entity filter, and the paper never states that such filters are rejected or automatically moved to ASSUMING. For example, `WHERE COUNT(TRANSACTIONS.*, 0, 30, days) > 0` is syntactically valid under `filtered_column: column WHERE condition` and `aggregation: AGGR_TYPE(... (INT | '-INF') ',' INT ',' TIME_UNIT)`. Executing this query selects only entities that have a positive label in the next 30 days, biasing the training sample and leaking label information. This is not a schema-cleanliness issue; it occurs even with perfectly timestamped, non-retroactively modified data. The paper's claim in Section 1 that PQL 'native[ly] enforce[s] temporal semantics and leakage-free data construction' is therefore not supported by the grammar. The implementation section (§3.9) lists only 'standard' validations and 'consistency wi
  2. [Section 3.2 and Section 4.2] The paper's own limitation statement in Section 5 acknowledges that real-world databases may not satisfy the clean-schema assumptions. This is appropriately candid, but the consequence is stronger than the paper states: when records lack reliable timestamps or are retroactively modified, the paper concedes that 'the procedure of generating training data from the past records is bound to produce inaccurate labels.' Given that this is a core assumption behind the leakage-free guarantee, the paper should either provide a formal statement of what property holds under the assumptions (and prove it for the given grammar) or explicitly scope the guarantee to the assumption set and discuss how the implementation detects violations. As written, the guarantee is only a best-effort property delegated to database hygiene.
  3. [Section 4.2, Table 1 and Figure 15] The experimental section measures runtime but never checks the correctness of the generated training tables. There is no comparison of PQL-generated labels against a hand-computed ground truth on a small dataset, no assertion that the number of generated rows matches the expected count, and no publicly released code or artifact. For a paper whose central value proposition is automated label generation, this is a significant omission. Additionally, the large-scale H&M experiment is run on a 'synthetically-upscaled variant' obtained by duplicating rows, not on an independent real dataset, which weakens the scalability claim. The authors should add at minimum a correctness validation on the rel-Amazon or Fannie Mae queries and publish the queries and generated label counts, or provide an artifact that permits independent verification.
minor comments (5)
  1. [Figure 5] Caption contains a typo: 'TRANSCTION_ID' should be 'TRANSACTION_ID'.
  2. [Section 4.3] The sentence beginning 'ecause all aggregations...' has a missing 'B'.
  3. [Sections 3.3-3.5] The grammar omits the concrete definitions of terminal symbols and the exact list of non-essential components. While this is stated, the paper would benefit from a small appendix giving the full grammar, since the temporal-offset semantics are central to the leakage argument.
  4. [Section 4.2, Table 1] The table column headers 'none', 'X-join', 'Filter', 'both' are not defined in the table caption. Please define them and also state whether the reported times include Spark startup and planning time.
  5. [Section 3.7] The claim that comparing predictions with and without an ASSUMING clause 'allows estimation of the impact of sending a notification' overstates causal identifiability. The comparison can be confounded by selection and by the timing of the assumed event. Rephrase as a description of conditional prediction, not causal estimation.

Circularity Check

0 steps flagged

No significant circularity: PQL's semantics are definitional and its benchmark comparisons are anchored on external RelBench data; self-citations are not load-bearing.

full rationale

This is a language-design paper, not a fitted-parameter derivation. The main claims are that the PQL grammar (Fig. 6) can express entity/target pairs and that the implementations can materialize training tables; both are checked by construction and by execution-time benchmarks on external RelBench datasets (rel-Amazon, Fannie Mae, H&M), not by any parameter fit to the claimed results. The 'prediction' language is definitional: task type is read off from the grammar and schema semantics (Sec. 3.6), so there is no hidden input-to-output reduction. The leakage-free architecture is a design property that separates ASSUMING as the future-looking filter (Sec. 3.7) and samples anchor times per the RDL blueprint (Sec. 3.8), and the admitted limitation in Sec. 5 about dirty schemas is an assumption failure, not a circular inference. The paper does rely on the authors' own prior RDL/RelBench/RFM work for terminology and task taxonomy, but those works are published external anchors with independent data, and no load-bearing uniqueness theorem is imported; therefore the self-citations do not make the argument circular. The skeptic's concern about future-referencing WHERE conditions is a correctness/validation gap in the language specification, not a case where an output is equivalent to an input by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

No numerical parameters are fitted to data, and no new physical or conceptual entities are postulated. The central claim rests on database-schema hygiene and timestamp integrity assumptions rather than free parameters. PQL itself is a language artifact, not an invented entity in the sense of a new force or mediator.

axioms (4)
  • domain assumption Database schemas are known in advance with clearly defined primary keys, foreign keys, and timestamp columns.
    Section 3.2: PQL relies on schema annotations for join inference and time-window aggregations. The paper later concedes real-world schemas are often messier.
  • domain assumption All entities are primary keys from a single column, or can be made so via auxiliary-table pre-processing.
    Section 3.2 and Section 5: non-atomic entities such as pairs of items require an auxiliary table; the core language design assumes single-column primary keys.
  • domain assumption Records are inserted with correct timestamps and historical records are not retroactively modified without a timestamped record.
    Explicitly stated as a limitation in Section 5: if this fails, 'the procedure of generating training data from the past records is bound to produce inaccurate labels.' This is load-bearing for the leakage-free claim.
  • domain assumption Each column carries data type and semantic type annotations (auto-inferred or user-specified).
    Section 3.2: task-type inference depends on these annotations, e.g. distinguishing numerical vs categorical columns and foreign-key columns.

pith-pipeline@v1.3.0-alltime-deepseek · 17159 in / 9078 out tokens · 94448 ms · 2026-08-03T02:44:49.376030+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of Predictive Query Language: A Domain-Specific Language for Predictive Modeling on Relational Databases." pith.science (2026). https://pith.science/paper/T2RUD2WD

@misc{pith2026260209572,
  author       = {Pith},
  title        = {Pith review of: Predictive Query Language: A Domain-Specific Language for Predictive Modeling on Relational Databases},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/T2RUD2WD}},
  note         = {Machine review of arXiv:2602.09572}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

The purpose of predictive modeling on relational data is to predict future or missing values in a relational database, for example, future purchases of a user, risk of readmission of the patient, or the likelihood that a financial transaction is fraudulent. Typically powered by machine learning methods, predictive models are used in recommendations, financial fraud detection, supply chain optimization, and other systems, providing billions of predictions every day. However, training a machine learning model requires manual work to extract the required training examples - prediction entities and target labels - from the database, which is slow, laborious, and prone to mistakes. Here, we present the Predictive Query Language (PQL), an SQL-inspired declarative language for defining predictive tasks on relational databases. PQL allows specifying a predictive task in a single declarative query, enabling the automatic computation of training labels for a large variety of machine learning tasks, such as regression, classification, time-series forecasting, and recommender systems. PQL is already successfully integrated and used in a collection of use cases as part of a predictive AI platform. The versatility of the language can be demonstrated through its many ongoing use cases, including financial fraud, item recommendations, and workload prediction. We demonstrate its versatile design through two implementations; one for small-scale, low-latency use and one that can handle large-scale databases.

Figures

Figures reproduced from arXiv: 2602.09572 by Federico Reyes Gomez, Jan Eric Lenssen, Jinu Sunil, Jure Leskovec, Matthias Fey, Vid Kocijan, Viman Deb, Xinwei Xe.

Figure 1
Figure 1. Figure 1: Predictive Query Overview. PQL allows for declaring a prediction task by formulating a query: The PREDICT statement describes what is to be predicted and the FOR EACH and WHERE statements for whom the prediction is to be made. In this example, the query is specifying a regression task of predicting the sum of transaction amounts over the next 30 days for all customers coming from New York. The predictive q… view at source ↗
Figure 2
Figure 2. Figure 2: Taxonomy of the Predictive Query Language (PQL). [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Predictive Query Example. An instance of a query to predict demand for shirts over the next three months. In PQL ( [PITH_FULL_IMAGE:figures/full_fig_p002_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Example database schema. An example retail database consisting of all customers, articles, and their timestamped transactions and notifications, serving as basis for the running query examples. Each row contains information about the data type and semantic type, with links between keys marked with arrows. Primary keys (PK) are highlighted in blue and foreign keys (FK) in orange. If PQL example from [PITH_… view at source ↗
Figure 5
Figure 5. Figure 5: shows an example of a simple query that predicts miss￾ing transaction values in the database, using all available transaction values as training data. The full grammar of PQL is provided in [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: PQL grammar. The grammar is implemented in ANTLR4 syntax [30]. Parts of the grammar, including selected terminal sym￾bols, are omitted for brevity. PREDICT TRANSACTIONS.VALUE > 100 FOR EACH TRANSACTIONS.TRANSACTION_ID WHERE CUSTOMERS.LOCATION_ID = "New York" [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗
Figure 8
Figure 8. Figure 8: Timeline example. Example of a temporal predictive query that predicts whether an active user will either spend at least 100 dollars in the time period between 15 and 45 days in the future, or have at least 10 transactions. The image below illustrates the decomposition of a single timeframe that operates on 85 days of data (40 days in the past and 45 in the future of the anchor timestamp). PREDICT SUM(tran… view at source ↗
Figure 9
Figure 9. Figure 9: Timeline example. In this example we augment the example from [PITH_FULL_IMAGE:figures/full_fig_p007_9.png] view at source ↗
Figure 12
Figure 12. Figure 12: Example of a commercial recommendation usecase. [PITH_FULL_IMAGE:figures/full_fig_p008_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Example of a commercial usecase of counterfactual [PITH_FULL_IMAGE:figures/full_fig_p008_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Example of a commercial usecase of behavior mod [PITH_FULL_IMAGE:figures/full_fig_p008_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: PQL for RFM execution time. Comparison of PQL ex￾ecution time for different context sizes, compared to a naive Pandas implementation. Experiments were run on the H&M dataset [33]. All running times were averaged over 10 random seeds and do not involve data reading. PQL implementation is significantly faster and more consistent, due to its ability to efficiently access the rele￾vant subset of the database.… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Universal Encoders for Modular Relational Deep Learning

    cs.LG 2026-06 unverdicted novelty 6.0

    Proposes a pretrained Universal Row Encoder using transformers and global statistics to generate table-width invariant row embeddings for modular relational graph models, claiming improved transfer, convergence, and m...

  2. OpenRFM: Dissecting Relational In-Context Learning

    cs.LG 2026-06 unverdicted novelty 6.0

    OpenRFM combines a relational transformer backbone with a batch-level ICL layer and homophily-aware synthetic-plus-real pre-training to improve relational in-context learning by ~30% over prior open models and surpass...

  3. KumoRFM-2: Scaling Foundation Models for Relational Learning

    cs.LG 2026-04 unverdicted novelty 6.0

    KumoRFM-2 pre-trains on synthetic and real relational data across row, column, foreign-key and cross-sample axes, injects task information early, and achieves up to 8% gains over supervised baselines on 41 benchmarks ...

Reference graph

Works this paper leans on

41 extracted references · 2 canonical work pages · cited by 3 Pith papers

  1. [1]

    Dusenberry, Deron Eriksson, Alexandre V

    Matthias Boehm, Michael W. Dusenberry, Deron Eriksson, Alexandre V. Ev- fimievski, Faraz Makari Manshadi, Niketan Pansare, Berthold Reinwald, Fred- erick R. Reiss, Prithviraj Sen, Arvind C. Surve, and Shirish Tatikonda. 2016. SystemML: declarative machine learning on spark.Proc. VLDB Endow.9, 13 (Sept. 2016), 1425–1436. https://doi.org/10.14778/3007263.3007279

  2. [2]

    Tianlang Chen, Charilaos Kanatsoulis, and Jure Leskovec. 2025. Relgnn: Compos- ite message passing for relational deep learning.arXiv preprint arXiv:2502.06784 (2025)

  3. [3]

    Victor Chernozhukov, Christian Hansen, Nathan Kallus, Martin Spindler, and Vasilis Syrgkanis. 2024. Applied Causal Inference Powered by ML and AI. arXiv:2403.02467 [econ.EM] https://arxiv.org/abs/2403.02467

  4. [4]

    Vijay Prakash Dwivedi, Sri Jaladi, Yangyi Shen, Federico López, Charilaos I Kanatsoulis, Rishi Puri, Matthias Fey, and Jure Leskovec. 2026. Relational Graph Transformer

  5. [5]

    Nick Erickson, Jonas Mueller, Alexander Shirkov, Hang Zhang, Pedro Larroy, Mu Li, and Alexander Smola. 2020. Autogluon-tabular: Robust and accurate automl for structured data.arXiv preprint arXiv:2003.06505(2020)

  6. [6]

    Matthias Feurer, Aaron Klein, Katharina Eggensperger, Jost Tobias Springen- berg, Manuel Blum, and Frank Hutter. 2015. Efficient and robust automated machine learning. InProceedings of the 29th International Conference on Neural Information Processing Systems - Volume 2(Montreal, Canada)(NIPS’15). MIT Press, Cambridge, MA, USA, 2755–2763

  7. [7]

    Matthias Fey, Weihua Hu, Kexin Huang, Jan Eric Lenssen, Rishabh Ranjan, Joshua Robinson, Rex Ying, Jiaxuan You, and Jure Leskovec. 2023. Position: Relational Deep Learning - Graph Representation Learning on Relational Databases. In Forty-first International Conference on Machine Learning. Vid Kocijan, Jinu Sunil, Jan Eric Lenssen, Viman Deb, Xinwei Xe, Fe...

  8. [8]

    Matthias Fey, Vid Kocijan, Federico Lopez, Jan Eric Lenssen, and Jure Leskovec

  9. [9]

    Matthias Fey, Jinu Sunil, Akihiro Nitta, Rishi Puri, Manan Shah, Blaž Stojanovič, Ramona Bendias, Alexandria Barghi, Vid Kocijan, Zecheng Zhang, Xinwei He, Jan Eric Lenssen, and Jure Leskovec. 2025. PyG 2.0: Scalable Learning on Real World Graphs. arXiv:2507.16991 [cs.LG] https://arxiv.org/abs/2507.16991

  10. [10]

    Ullman, and Jennifer D

    Hector Garcia-Molina, Jeffrey D. Ullman, and Jennifer D. Widom. 2002.Database systems : the complete book(2nd ed. ed.). Prentice Hall

  11. [11]

    Amol Ghoting, Rajasekar Krishnamurthy, Edwin Pednault, Berthold Rein- wald, Vikas Sindhwani, Shirish Tatikonda, Yuanyuan Tian, and Shivakumar Vaithyanathan. 2011. SystemML: Declarative machine learning on MapReduce. InProceedings of the 2011 IEEE 27th International Conference on Data Engi- neering (ICDE ’11). IEEE Computer Society, Washington, DC, USA, 23...

  12. [12]

    Hamilton, Rex Ying, and Jure Leskovec

    William L. Hamilton, Rex Ying, and Jure Leskovec. 2017. Inductive representation learning on large graphs. InProceedings of the 31st International Conference on Neural Information Processing Systems(Long Beach, California, USA)(NIPS’17). Curran Associates Inc., Red Hook, NY, USA, 1025–1035

  13. [13]

    Hellerstein, Christoper Ré, Florian Schoppmann, Daisy Zhe Wang, Eugene Fratkin, Aleksander Gorajek, Kee Siong Ng, Caleb Welton, Xixuan Feng, Kun Li, and Arun Kumar

    Joseph M. Hellerstein, Christoper Ré, Florian Schoppmann, Daisy Zhe Wang, Eugene Fratkin, Aleksander Gorajek, Kee Siong Ng, Caleb Welton, Xixuan Feng, Kun Li, and Arun Kumar. 2012. The MADlib analytics library: or MAD skills, the SQL.Proc. VLDB Endow.5, 12 (Aug. 2012), 1700–1711. https://doi.org/10. 14778/2367502.2367510

  14. [14]

    Noah Hollmann, Samuel Müller, Lennart Purucker, Arjun Krishnakumar, Max Körfer, Shi Bin Hoo, Robin Tibor Schirrmeister, and Frank Hutter. 2025. Accurate predictions on small data with a tabular foundation model.Nature(09 01 2025). https://doi.org/10.1038/s41586-024-08328-6

  15. [15]

    Weihua Hu, Yiwen Yuan, Zecheng Zhang, Akihiro Nitta, Kaidi Cao, Vid Kocijan, Jure Leskovec, and Matthias Fey. 2024. PyTorch Frame: A Modular Framework for Multi-Modal Tabular Learning.arXiv preprint arXiv:2404.00776(2024)

  16. [16]

    Lew, Ulrich Schaechtle, Cameron E

    Mathieu Huot, Matin Ghavami, Alexander K. Lew, Ulrich Schaechtle, Cameron E. Freer, Zane Shelby, Martin C. Rinard, Feras A. Saad, and Vikash K. Mansinghka

  17. [17]

    James Kanter and Kalyan Veeramachaneni. 2015. Deep feature synthesis: Towards automating data science endeavors. 1–10. https://doi.org/10.1109/DSAA.2015. 7344858

  18. [18]

    Steffen Kläbe, Stefan Hagedorn, and Kai-Uwe Sattler. 2023. Exploration of Ap- proaches for In-Database ML. InInternational Conference on Extending Database Technology. https://api.semanticscholar.org/CorpusID:253270276

  19. [19]

    Tim Kraska, Ameet Talwalkar, John C Duchi, Rean Griffith, Michael J Franklin, and Michael I Jordan. 2013. MLbase: A Distributed Machine-learning System.. In Cidr, Vol. 1. 2–1

  20. [20]

    Hoang Thanh Lam, Johann-Michael Thiebaut, Mathieu Sinn, Bei Chen, Tiep Mai, and Oznur Alkan. 2017. One button machine for automating feature engineering in relational databases.arXiv preprint arXiv:1706.00327(2017)

  21. [21]

    Nantia Makrynioti, Ruy Ley-Wild, and Vasilis Vassalos. 2019. sql4ml A declarative end-to-end workflow for machine learning. arXiv:1907.12415 [cs.DB] https: //arxiv.org/abs/1907.12415

  22. [22]

    Baylor, Eric Breck, Heng-Tze Cheng, Jarek Wilkiewicz, Levent Koc, Lukasz Lew, Martin A

    Akshay Naresh Modi, Chiu Yuen Koo, Chuan Yu Foo, Clemens Mewald, Denis M. Baylor, Eric Breck, Heng-Tze Cheng, Jarek Wilkiewicz, Levent Koc, Lukasz Lew, Martin A. Zinkevich, Martin Wicke, Mustafa Ispir, Neoklis Polyzotis, Noah Fiedel, Salem Elie Haykal, Steven Whang, Sudip Roy, Sukriti Ramesh, Vihan Jain, Xin Zhang, and Zakaria Haque. 2017. TFX: A TensorFl...

  23. [23]

    Piero Molino, Yaroslav Dudin, and Sai Sumanth Miryala. 2019. Ludwig: a type- based declarative deep learning toolbox. arXiv:1909.07930 [cs.LG] https://arxiv. org/abs/1909.07930

  24. [24]

    Muchnick

    Steven S. Muchnick. 1998.Advanced compiler design and implementation. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA

  25. [25]

    Samuel Müller, Simon Kornblith, and Ioannis Pitas. 2022. Transformers Can Do Bayesian Inference. InInternational Conference on Learning Representations

  26. [26]

    Jianmo Ni, Jiacheng Li, and Julian McAuley. 2019. Justifying Recommendations using Distantly-Labeled Reviews and Fine-Grained Aspects. InProceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), Kentaro Inui, Jing Jiang, Vincent Ng, and X...

  27. [27]

    Olson and Jason H

    Randal S. Olson and Jason H. Moore. 2016. TPOT: A Tree-based Pipeline Opti- mization Tool for Automating Machine Learning. InProceedings of the Workshop on Automatic Machine Learning (Proceedings of Machine Learning Research), Frank Hutter, Lars Kotthoff, and Joaquin Vanschoren (Eds.), Vol. 64. PMLR, New York, New York, USA, 66–74. https://proceedings.mlr...

  28. [28]

    2020.pandas-dev/pandas: Pandas

    The pandas development team. 2020.pandas-dev/pandas: Pandas. https://doi. org/10.5281/zenodo.3509134

  29. [29]

    Kwanghyun Park, Karla Saur, Dalitso Banda, Rathijit Sen, Matteo Interlandi, and Konstantinos Karanasos. 2022. End-to-end optimization of machine learn- ing prediction queries. InProceedings of the 2022 International Conference on Management of Data. 587–601

  30. [30]

    2013.The Definitive ANTLR 4 Reference(2nd ed.)

    Terence Parr. 2013.The Definitive ANTLR 4 Reference(2nd ed.). Pragmatic Bookshelf

  31. [31]

    Jingang Qu, David Holzmüller, Gaël Varoquaux, and Marine Le Morvan. 2025. TabICL: A Tabular Foundation Model for In-Context Learning on Large Data. arXiv preprint arXiv:2502.05564(2025)

  32. [32]

    Rishabh Ranjan, Valter Hudovernik, Mark Znidar, Charilaos Kanatsoulis, Roshan Upendra, Mahmoud Mohammadi, Joe Meyer, Tom Palczewski, Carlos Guestrin, and Jure Leskovec. 2026. Relational Transformer: Toward Zero-Shot Foundation Models for Relational Data. (April 2026)

  33. [33]

    Lenssen, Yiwen Yuan, Zecheng Zhang, Xinwei He, and Jure Leskovec

    Joshua Robinson, Rishabh Ranjan, Weihua Hu, Kexin Huang, Jiaqi Han, Alejandro Dobles, Matthias Fey, Jan E. Lenssen, Yiwen Yuan, Zecheng Zhang, Xinwei He, and Jure Leskovec. 2024. RelBench: A Benchmark for Deep Learning on Relational Databases. arXiv:2407.20060 [cs.LG] https://arxiv.org/abs/2407.20060

  34. [34]

    Christopher Ré, Feng Niu, Pallavi Gudipati, and Charles Srisuwananukorn. 2019. Overton: A Data System for Monitoring and Improving Machine-Learned Prod- ucts. InCIDR. https://arxiv.org/pdf/1909.05372.pdf

  35. [35]

    Schüle, Matthias Bungeroth, Alfons Kemper, Stephan Günnemann, and Thomas Neumann

    Maximilian E. Schüle, Matthias Bungeroth, Alfons Kemper, Stephan Günnemann, and Thomas Neumann. 2019. MLearn: A Declarative Machine Learning Lan- guage for Database Systems. InProceedings of the 3rd International Workshop on Data Management for End-to-End Machine Learning(Amsterdam, Netherlands) (DEEM’19). Association for Computing Machinery, New York, NY...

  36. [36]

    Evan R Sparks, Shivaram Venkataraman, Tomer Kaftan, Michael J Franklin, and Benjamin Recht. 2017. Keystoneml: Optimizing pipelines for large-scale advanced analytics. In2017 IEEE 33rd international conference on data engineering (ICDE). IEEE, 535–546

  37. [37]

    2025.SparkR: R Front End for ’Apache Spark’

    The Apache Software Foundation. 2025.SparkR: R Front End for ’Apache Spark’

  38. [38]

    Chris Thornton, Frank Hutter, Holger H Hoos, and Kevin Leyton-Brown. 2013. Auto-WEKA: Combined selection and hyperparameter optimization of classifica- tion algorithms. InProceedings of the 19th ACM SIGKDD international conference on Knowledge discovery and data mining. 847–855

  39. [39]

    Doris Xin, Litian Ma, Jialin Liu, Stephen Macke, Shuchen Song, and Aditya Parameswaran. 2018. Helix: Accelerating human-in-the-loop machine learning. arXiv preprint arXiv:1808.01095(2018)

  40. [2024]

    ACM Program

    GenSQL: A Probabilistic Programming System for Querying Generative Models of Database Tables.Proc. ACM Program. Lang.8, PLDI, Article 179 (June 2024), 26 pages. https://doi.org/10.1145/3656409

  41. [2025]

    https://kumo.ai/research/kumo_relational_foundation_model.pdf

    KumoRFM: A Foundation Model for In-Context Learning on Relational Data. https://kumo.ai/research/kumo_relational_foundation_model.pdf