SEMA-SQL: Bridging Relational and Semantic Querying
- SEMA-SQL is a polysemous term encompassing multiple research approaches that extend SQL with semantic operators and frameworks for mixed structured–semantic query processing.
- It combines exact relational predicates with semantic similarity measures to enable effective querying over both structured data and unstructured content.
- Optimization techniques in SEMA-SQL include dynamic programming, cost-based planning, and LLM UDF rewrites to reduce execution time and improve accuracy.
SEMA-SQL is a polysemous label in recent data-management and Text-to-SQL literature rather than a single standardized system. In the cited corpus, it refers to at least four distinct lines of work: a mixed-query framework that combines relational predicates with semantic vector retrieval over unstructured data; an LLM-augmented query system based on Hybrid Relational Algebra; a Semantic SQL Transducer that materializes a lossless conceptual view of relational data; and SQL-adjacent Text-to-SQL methods that use semantic layers or semantically enriched schema representations to improve grounding and synthesis (Mittal et al., 2024, Abgrall et al., 2024, Lin et al., 26 Apr 2026, Yang et al., 2024). The shared theme is the attempt to bridge exact relational processing with meanings, relations, or concepts that are not fully captured by conventional schema-level SQL alone.
1. Terminological scope and major usages
The term’s ambiguity is itself technically important, because the underlying systems solve different problems and operate at different layers of the stack.
| Usage of the label | Core objective | Representative paper |
|---|---|---|
| SSQL – Semantic SQL | Combine SQL predicates with semantic predicates over unstructured data | (Mittal et al., 2024) |
| SEMA-SQL | Generate, optimize, and execute HRA queries with LLM UDFs | (Lin et al., 26 Apr 2026) |
| Semantic SQL Transducer | Produce a materialised lossless conceptual view of relational source data | (Abgrall et al., 2024) |
| SQL-to-Schema | Improve schema linking by generating initial SQL and extracting a concise schema | (Yang et al., 2024) |
In the first sense, semantic SQL is a query language extension for mixed structured/unstructured retrieval. In the second, it is a broader execution framework in which LLM-powered semantic operators become first-class elements of query planning and execution. In the third, it is a conceptual-model transducer from physical tables to business-facing semantic objects. In the fourth, the term is attached to a Text-to-SQL schema-linking method rather than an execution-time semantic operator system. A common misconception is to treat these as variants of one architecture; the papers instead describe distinct abstractions with different formal objects, optimizers, and evaluation protocols (Mittal et al., 2024, Abgrall et al., 2024, Yang et al., 2024, Lin et al., 26 Apr 2026).
2. Mixed structured–semantic querying over unstructured data
In "Semantic SQL -- Combining and optimizing semantic predicates in SQL" (Mittal et al., 2024), the system is called SSQL – Semantic SQL and addresses a gap between two established practices for unstructured data. One stores ML model outputs and metadata in relational tables and queries them with SQL; the other embeds content into a vector space and performs semantic retrieval. The paper’s central claim is that neither approach alone is sufficient. SQL over ML-derived tables is effective for exact properties that have already been modeled, such as object class, count, bounding box location, or timestamp filters. Semantic retrieval is effective for contextual notions such as “snowy weather,” “big green car,” “women no kids,” or “men in suits,” but it loses exact cardinality, precise spatial geometry, and metadata constraints (Mittal et al., 2024).
The language extension is intentionally minimal: a standard SQL query is augmented with a SEMANTIC clause containing a natural-language predicate. A representative example is:
1 2 3 |
SELECT DISTINCT frame FROM object_detection_results WHERE class = 'car' AND x_max < 500 SEMANTIC = 'big green car'; |
The executor splits the query into a base SQL part and a semantic predicate. It executes the base SQL query on the relational database, computes similarity between the SQL results and the semantic query, and returns results using a feedback-guided thresholding loop. The paper notes that currently only one semantic predicate is supported per query. This design lets exact relational logic restrict the candidate set before semantic ranking is applied, which is a form of selection pushdown and candidate pruning (Mittal et al., 2024).
The empirical motivation is explicit. On the COCO dataset, using a random sample of 20k images with around 145k object instances, the paper evaluates multiple-object, count, spatial locality, and contextual queries. It reports that semantic-only approaches fail catastrophically for count and spatial queries in more than 60% of cases. For multiple-object queries, 2124 object pairs were tested and only 608 pairs were successfully satisfied by the semantic query. The paper therefore positions mixed queries—such as images with one person, an umbrella, exactly two cars, and the semantic predicate “women no kids”—as the central use case for SSQL (Mittal et al., 2024).
3. From SQL extension to semantic algebra and LLM operators
The 2026 paper titled "SEMA-SQL: Beyond Traditional Relational Querying with LLMs" reframes the problem at a more general level (Lin et al., 26 Apr 2026). Its core abstraction is Hybrid Relational Algebra (HRA), which combines ordinary relational operators with LLM-powered UDFs. In this formulation, semantic selection uses an LLM UDF as a Boolean classifier over tuples, semantic projection performs extraction or transformation, semantic join performs pairwise semantic matching, semantic TopK uses pairwise comparison, and semantic aggregation performs summarization or group-level semantic reasoning. The system is designed to answer natural-language questions automatically by generating HRA queries via in-context learning, optimizing them with cost-based transformations and UDF rewriting, and executing them efficiently (Lin et al., 26 Apr 2026).
This HRA-based formulation belongs to a broader movement toward algebraic foundations for semantic query processing. "SABER: A SQL-Compatible Semantic Document Processing System Based on Extended Relational Algebra" proposes 12 conventional relational algebra operators and 10 semantic relational operators, marking semantic forms with a superscript sem, such as σ^sem, π^sem, Join^sem, γ^sem, ξ^sem, δ^sem, and τ^sem (Lee et al., 29 Aug 2025). The paper’s main claim is that semantic operators preserve the overall algebraic shape of their relational counterparts, so equivalences such as selection push-down, projection composition, and duplicate-elimination propagation can be reused under appropriate semantic equivalence. SABER exposes these operators through SQL-compatible UDFs such as SEM_WHERE(...), SEM_SELECT(...), SEM_JOIN(...), SEM_GROUP_BY(...), SEM_AGG(...), SEM_DISTINCT(...), and SEM_ORDER_BY(...) (Lee et al., 29 Aug 2025).
"Sema: A High-performance System for LLM-based Semantic Query Processing" advances a closely related systems view (Qi et al., 12 Mar 2026). Built on DuckDB, Sema treats semantic operators as first-class citizens inside the planner and executor rather than as opaque SQL UDFs or DataFrame-side logic. Its SemaSQL dialect injects natural-language expressions directly into standard SQL clauses: semantic filters appear in WHERE or HAVING, semantic projections in SELECT, semantic joins in JOIN ON, and semantic aggregates in sem_agg(...). A plausible implication is that SEMA-SQL, SABER, and Sema together mark a convergence toward making semantic operators visible to the optimizer, rather than burying them behind black-box application code (Lin et al., 26 Apr 2026, Lee et al., 29 Aug 2025, Qi et al., 12 Mar 2026).
4. Optimization, execution, and cardinality estimation
Optimization is a central research problem for SEMA-SQL-style systems because semantic operators are expensive, model-dependent, and often nondeterministic. Even the early SSQL framework already adopts a clear optimization principle: execute exact relational predicates first, then apply semantic similarity on the reduced candidate set, with FAISS used to accelerate embedding retrieval and human-in-the-loop thresholding used to convert top- retrieval into an “all matching items” interface (Mittal et al., 2024).
The 2026 HRA-based SEMA-SQL system makes this optimizer story explicit (Lin et al., 26 Apr 2026). It defines a plan cost model that separates relational and semantic operator costs, then searches for semantically equivalent plans that minimize total execution cost. A bottom-up dynamic programming algorithm performs lazy placement of semantic operators, and equivalence of rewrites is checked with symbolic execution using Z3, treating LLM UDFs as uninterpreted functions. The system also attempts UDF rewriting when an LLM predicate is stateless, deterministic, and expressible in SQL. On 120 benchmark queries, 33 plans were optimized; average runtime decreased from 62.9s to 45.1s, and token usage dropped from 31.5K to 25.0K. For semantic joins, the paper reports that smart batching reduces LLM invocations by 93.3% on average across 10 benchmark join queries while maintaining 100% execution accuracy (Lin et al., 26 Apr 2026).
Sema extends optimization into runtime adaptivity (Qi et al., 12 Mar 2026). Its logical optimizer performs expression compression and predicate deduction, extracting necessary SQL predicates from natural-language expressions so that cheap relational filters can be pushed down without removing true positives. At runtime, Adaptive Query Execution (AQE) explores alternative plans that differ in operator order, fusion, and batching, using sample-based measurements of selectivity, token cost, latency, and output agreement relative to a reference path. Candidate plans are filtered by an accuracy threshold, and the system chooses a Pareto-optimal plan balancing token consumption and latency under accuracy constraints. Across 20 semantic queries, Sema reports 2–10× speedup against three baselines while achieving competitive result quality (Qi et al., 12 Mar 2026).
Cardinality estimation becomes a bottleneck once semantic filters and semantic joins enter the optimizer. "SemCEB: A Cardinality Estimation Benchmark for Semantic Operators" positions itself as the first benchmark for this problem in semantic SQL / SEMA-SQL-style systems (Zimmerer et al., 22 Jun 2026). It contains 102 hand-curated queries—62 semantic filters and 40 semantic joins—over a multimodal dataset derived from Amazon Reviews 2023, and evaluates estimators with q-error. The paper gives a concrete demonstration of optimizer sensitivity: a query with two semantic joins and several filters had 96 semantically equivalent execution plans; the cheapest cost \$0.119**, the most expensive **\$2.869, a 24.1× difference, while wrong filter ordering alone still caused a 1.43× increase. Sampling-based estimators are reported as robust but expensive, whereas the evaluated adaptation of Semantic Histograms is cheaper yet less accurate and limited to single-column filters on only 31 of the 102 queries (Zimmerer et al., 22 Jun 2026). This directly counters the misconception that semantic SQL systems can rely on fixed selectivity heuristics.
5. Semantic layers, schema grounding, and Text-to-SQL variants
A second major usage of the SEMA-SQL label appears in systems that mediate between natural language and SQL through a semantic abstraction rather than by embedding semantic operators directly into the final query. "A Semantic-Layer-Mediated Agent for Natural Language to SQL over Heterogeneous Enterprise Databases" introduces a semantic layer and a compact intermediate representation called the Semantic Model Query (SMQ) (Kim et al., 30 Jun 2026). Instead of reasoning over raw schemas, the agent reasons over semantic models containing typed, described elements, then calls a deterministic compiler to translate SMQ into dialect-specific SQL for SQLite, BigQuery, and Snowflake. Using Gemini 3 Pro, the system reports 94.15% execution accuracy on the 547-task Spider2-snow benchmark, with 515 / 547 correct and third place on the official leaderboard (Kim et al., 30 Jun 2026). The paper explicitly frames the semantic layer as a mechanism for decoupling intent from physical execution and reducing hallucination through compiler-validated table names, column expressions, and join patterns.
Other papers use semantically enriched intermediate representations to improve Text-to-SQL grounding rather than execution-time semantic querying. "SQL-to-Schema Enhances Schema Linking in Text-to-SQL" defines a two-step pipeline in which an LLM first generates SQL0 over the full schema, then extracts tables and columns from that SQL to form a concise linking schema (Yang et al., 2024). Iterative refinement yields Schema1, Schema2, and Schema3, with Spider dev table-recall@4 improving from 0.95 to 0.978 and 0.981. With GPT-4-turbo, SCVSQL reaches 0.824 execution accuracy. The paper’s central claim is that SQL itself is a better intermediate signal for schema selection than direct question-to-schema similarity (Yang et al., 2024).
Related work pushes this semantic-grounding agenda further. "Semantic Enhanced Text-to-SQL Parsing via Iteratively Learning Schema Linking Graph" constructs a semantic schema-linking graph from PLM probing and iterative graph refinement, reporting larger gains on Spider-SYN and Spider-DK, where lexical overlap is weaker and semantic inference matters more (Liu et al., 2022). "SEA-SQL: Semantic-Enhanced Text-to-SQL with Adaptive Refinement" uses a semantic-enhanced schema with retrieved column values, a fine-tuned adaptive bias eliminator, and dynamic execution adjustment, reaching 83.6 EX on Spider and 56.13 ACC / EX plus 60.13 VES on BIRD dev, with \$0.0065 per-query generation cost on BIRD dev (Li et al., 2024). "SemanticAgent: A Semantics-Aware Framework for Text-to-SQL Data Synthesis" argues that executability is not semantic validity and introduces analyzer, synthesizer, and verifier modules for semantic-aware synthetic data generation (Gao et al., 23 Apr 2026). "AgentSM: Semantic Memory for Agentic Text-to-SQL" stores prior execution traces as structured programs and reports a 25% reduction in average token usage, a 35% reduction in trajectory length, and 44.8% execution accuracy on Spider 2.0 Lite (Biswal et al., 22 Jan 2026). Taken together, these works suggest that one influential reading of SEMA-SQL is not “SQL plus semantic operators,” but “SQL generation grounded by a semantic abstraction layer.”
6. Semantic SQL as conceptual transduction and its limits
A third major interpretation appears in "Understanding the Semantic SQL Transducer" (Abgrall et al., 2024). Here, SEMA-SQL is not primarily a query language but a formal transducer that converts relational source data into a semantic, conceptual view that is simultaneously lossless and materialised. The source relation contains attributes such as SSN, Phone, Name, Dept, and DAddr. The target semantic schema introduces conceptual identifiers POID and DOID, then constructs semantic relations such as POID-Phone, POID-Name, POID-Dept, DOID-DAddr, POID-SSN, DOID-Dept, POID, and DOID through projection, selection, renaming, and self-products. The final recovery equation indicates that can be reconstructed from the semantic representation, which is the basis of the paper’s losslessness claim (Abgrall et al., 2024).
This transducer view is oriented toward knowledge-centric data stacks rather than semantic operator execution. Its purpose is to bridge the gap between technical schemas and business-facing conceptual entities, preserving identifiers and relationships while exposing people, departments, phones, and addresses as semantic objects. The paper explicitly instructs the system to eliminate tuples with NULL values during semantic materialization. It also implies several limits: the construction relies strongly on the choice of source identifiers such as SSN and Dept, the illustrated mapping is schema-specific, and the excerpt does not present ambiguity resolution, ontology alignment, or conflict handling (Abgrall et al., 2024). This is a different sense of “semantic SQL” from both SSQL and HRA-based SEMA-SQL, and it underscores why the term requires disambiguation in technical discussion.
Across these lines of work, several stable limitations recur. Semantic-only retrieval is poor for exact count and spatial queries (Mittal et al., 2024). Query optimization remains hard because semantic operators enlarge the plan space and demand accurate but cheap selectivity estimates (Zimmerer et al., 22 Jun 2026). HRA- and Sema-style systems remain dependent on underlying LLM behavior, prompt quality, and incomplete equivalence checking or rewrite coverage (Lin et al., 26 Apr 2026, Qi et al., 12 Mar 2026). Semantic-layer-mediated NL2SQL systems depend heavily on semantic-layer maturity and face a grounding-versus-overfitting trade-off (Kim et al., 30 Jun 2026). The broader lesson is that SEMA-SQL is best understood not as a settled language standard, but as an active research area spanning mixed-modal querying, semantic operator algebras, semantic-layer-mediated SQL generation, and conceptual transduction.
