---
title: 'SEMA-SQL: Bridging Relational and Semantic Querying'
url: https://www.emergentmind.com/topics/sema-sql
type: topic
---

# SEMA-SQL: Bridging Relational and Semantic Querying

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 [2404.03880] [2407.07502] [2604.23477] [2405.09593]. 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 | [2404.03880] |
| **SEMA-SQL** | Generate, optimize, and execute HRA queries with LLM UDFs | [2604.23477] |
| **Semantic SQL Transducer** | Produce a materialised lossless conceptual view of relational source data | [2407.07502] |
| **SQL-to-Schema** | Improve schema linking by generating initial SQL and extracting a concise schema | [2405.09593] |

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 [2404.03880] [2407.07502] [2405.09593] [2604.23477].

## 2. Mixed structured–semantic querying over unstructured data

In "Semantic SQL -- Combining and optimizing semantic predicates in SQL" [2404.03880], 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 [2404.03880].

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:

```sql
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 [2404.03880].

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 [2404.03880].

## 3. From SQL extension to semantic algebra and LLM operators

The 2026 paper titled "SEMA-SQL: Beyond Traditional Relational Querying with Large Language Models" reframes the problem at a more general level [2604.23477]. 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 [2604.23477].

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` [2509.00277]. 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(...)` [2509.00277].

"Sema: A High-performance System for LLM-based Semantic Query Processing" advances a closely related systems view [2603.11622]. 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 [2604.23477] [2509.00277] [2603.11622].

## 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-\(k\) retrieval into an “all matching items” interface [2404.03880].

The 2026 HRA-based SEMA-SQL system makes this optimizer story explicit [2604.23477]. 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** [2604.23477].

Sema extends optimization into runtime adaptivity [2603.11622]. 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 [2603.11622].

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 [2606.23081]. 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** [2606.23081]. 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)** [2606.31041]. 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 [2606.31041]. 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 [2405.09593]. 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 [2405.09593].

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 [2208.03903]. "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 [2408.04919]. "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 [2604.21414]. "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 [2601.15709]. 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" [2407.07502]. 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 \(T\) 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 \(T\) can be reconstructed from the semantic representation, which is the basis of the paper’s losslessness claim [2407.07502].

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 [2407.07502]. 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 [2404.03880]. Query optimization remains hard because semantic operators enlarge the plan space and demand accurate but cheap selectivity estimates [2606.23081]. HRA- and Sema-style systems remain dependent on underlying LLM behavior, prompt quality, and incomplete equivalence checking or rewrite coverage [2604.23477] [2603.11622]. Semantic-layer-mediated NL2SQL systems depend heavily on semantic-layer maturity and face a grounding-versus-overfitting trade-off [2606.31041]. 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.

Source: https://www.emergentmind.com/topics/sema-sql