Papers
Topics
Authors
Recent
Search
2000 character limit reached

SQL4ML: Bridging SQL and Machine Learning

Updated 2 July 2026
  • SQL4ML is a paradigm that integrates ML model specification and training directly into SQL using declarative views for predictions and loss functions.
  • It extends SQL with constructs like SEMANTIC predicates to support embedding-based similarity searches and ML inference over diverse data types.
  • The architecture employs cost-based optimizers and real-time feature engineering to streamline ML workflows and model introspection within the SQL ecosystem.

sql4ml refers to a paradigm, system design, and set of language extensions that bridge relational Structured Query Language (SQL) with ML workflows. Its core objective is to allow both ML model specification and typical database operations—including querying, feature engineering, and prediction or inference—within the SQL ecosystem, supporting both structured and unstructured data scenarios. Recent systems extend these integrations to encompass embedding-based and large-model inference, cost-based optimization, and model introspection.

1. Declarative Model Specification and Training in SQL

Traditional ML workflows separate the phases of data wrangling (in relational databases) and model training (in external ML frameworks), resulting in complex, fragmented engineering efforts. sql4ml, as formalized in (Makrynioti et al., 2019), enables expression of both model definitions and loss functions purely as SQL views and expressions, with no new keywords required. The user specifies the prediction function hθ(x)h_\theta(x) and an objective L(θ)L(\theta) over standard “feature” and “target” tables:

  • Feature and label storage in normalized tables (features(rowID,featureName,v), targets(rowID,v)).
  • Model parameters managed in a weights(featureName,v) table.
  • SQL views formulate predictions (e.g., for logistic regression, hθ(x)=1/(1+exθ)h_\theta(x) = 1/(1+e^{-x^\top\theta})) and loss expressions.
  • Feature engineering leverages full SQL expressiveness, including JOIN, GROUP BY, and aggregation.
  • There is no iteration or gradient calculation in SQL. Instead, the system translates the expressions to computational graphs in a backend (e.g., TensorFlow), generates batching, and orchestrates optimizer loops automatically; trained parameters are written back to the SQL database.

Supported algorithms include linear regression, logistic regression, and factorization machines. This design yields a unified workflow: model definition, preprocessing, training, and parameter management are database-native and decouple ML programming from imperative code (Makrynioti et al., 2019).

2. Extending SQL Semantics: Beyond Structured Data

Recent advancements have led to the augmentation of SQL with new constructs that support ML-specific queries over both structured and unstructured data:

  • Semantic SQL (SSQL): SQL is extended with the SEMANTIC predicate and operators (=, IN, SIMILAR TO θ), allowing embedding-based similarity searches to be intermixed with classical relational filters (Mittal et al., 2024). For example:

1
2
3
4
5
SELECT frame
FROM object_detection_results
WHERE class='car'
  AND x_max < 500
  SEMANTIC = 'big green car';

  • iPDB and SEMANTIC Clauses: SQL clauses such as SEMANTIC PROJECT, SEMANTIC SELECT, SEMANTIC JOIN, and SEMANTIC GROUP-BY permit in-database execution of arbitrary ML or LLM inference, tightly integrating learned models as first-class relational operators (Kumarasinghe et al., 23 Jan 2026). All such semantic clauses map to a generalized “predict” relational operator (denoted δ), formally defined as:

δy1,,ym(f,Tx1,,xn)={tf(t[x1xn])tT}\delta_{y_1, \dots, y_m}\,(f,\,T_{x_1, \dots, x_n}) = \{\,t \oplus f(t[x_1\dots x_n])\,|\,t \in T\}

3. SQL4ML System Architectures and Optimization

SQL4ML systems adopt architectures that compose relational and vector (embedding) stores or integrate ML/LLM model calls directly into the query execution plan:

  • Two-Store Architecture: Unstructured data (text, images) is stored as both embeddings in a vector store (e.g., FAISS) and as results or metadata in a relational database. SQL queries parsed with extended grammar trigger joint execution plans, where classical filters, ML outputs, and semantic predicates are joined and optimized (Mittal et al., 2024).
  • Cost-Based Optimizers: To mitigate the high cost of model inference, query planners employ detailed cost models, pushdown heuristics, and operator reordering. For example, in SSQL, optimizers automatically decide between applying relational filters before or after embedding-based filtering to minimize the total cost subject to accuracy constraints. In iPDB, the optimizer merges semantic predicates, deduplicates prompt inputs, and batch executes LLM calls, considering the large per-tuple cost of inference (Mittal et al., 2024, Kumarasinghe et al., 23 Jan 2026).
System Key SQL4ML Extension Optimization Strategies
SSQL SEMANTIC predicate Cost/accuracy models, human-in-the-loop threshold tuning, operator order selection
iPDB SEMANTIC SELECT/PROJECT/JOIN/AGG Cost annotations, deduplication, batching, prompt merging
SQLFlow TO TRAIN/PREDICT/EXPLAIN Collaborative parsing, code generation, k8s-native execution
OpenMLDB Extended window/ML UDFs Plan caching, parallel processing, index selection

4. Expressive Querying and Model-Intensive Data Management

SQL4ML encompasses the querying, validation, and interpretation of models as data:

  • Model Introspection: Using SQL4NN, neural network model parameters (nodes, edges) are stored as tables, enabling expressive queries for evaluation, structural analysis, and verification directly in SQL. Declarative patterns realize forward passes, neuron pruning, activation summary, and even piecewise-linear function geometry recovery for ReLU networks (Gerarts et al., 20 Feb 2025).
  • Statistical Quantile Learning (SQL): For nonlinear latent variable models, SQL formalism (unrelated to Structured Query Language but sharing the acronym) expresses additive factor models and fits them via convex assignment/matching and nonparametric sieves, offering identifiable, interpretable nonlinear reduction with performance advantages over PCA and black-box deep models (Bodelet et al., 2020).

5. Feature Engineering and Real-Time Inference

Feature computation for ML workloads is a central use case for SQL4ML, where high throughput, low-latency, and training-serving consistency are essential:

  • OpenMLDB achieves real-time SQL+ML execution by unifying batch and streaming feature pipelines, pre-aggregation for long window queries, plan caching, and highly parallel execution. These approaches eliminate training-serving skew and support feature re-use in both online scoring and offline model training with resource management and microsecond latency profiles (Sidiq et al., 19 Sep 2025, Zhou et al., 15 Jan 2025).
  • Rich windowing, aggregation, and specialized ML UDFs are first-class SQL constructs (e.g., topN_frequency, drawdown, multiclass_label), augmented with persistent indexes and memory-efficient formats (Zhou et al., 15 Jan 2025).

6. Optimization for ML Filters and Data Skipping

Integrating opaque ML model calls within SQL queries poses significant challenges for query planning and data access:

  • MLSkip demonstrates that black-box predicate pushdown for ML filters is feasible via metadata augmentation (min–max, convex hulls) and lightweight neural network verification. For ReLU networks in WHERE clauses on Parquet data, significant portions of data can be safely skipped, yielding measurable reductions in I/O and model computation (Stoian et al., 2 Jun 2026).

7. Ecosystem Extensions, Democratization, and Limitations

SQL-like declarative languages for ML (e.g., MQL) lower the barrier to entry, providing high-level abstractions for prediction, classification, and clustering that translate to backend ML code (e.g., SciKit-Learn, PyTorch). However, these systems are generally limited to single-table queries, lack native streaming or complex AutoML, and often rely on extension via UDFs or external interpreters for advanced functionality (Jamil, 2024).

Current sql4ml systems excel at unifying data management and ML workflows for supervised learning, embedding-rich queries, and model inspection. Open challenges include seamless support for deep models, full integration of unsupervised and generative learning paradigms, and robust performance for very large or highly dynamic workloads.


References:

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

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

Follow Topic

Get notified by email when new papers are published related to sql4ml.