Most LLM integrations with databases treat the model as a user-defined function — an opaque box the query planner cannot reason about. The LLM call happens outside the optimizer, invisible to cost estimation, unreachable by reordering rules, immune to batching. The planner optimizes the SQL around a black hole.
Sema (arXiv:2603.11622) makes the conceptual move of treating semantic operations as first-class SQL operators. SemaSQL injects natural language expressions directly into standard SQL clauses — WHERE, SELECT, GROUP BY — where the optimizer can see them, reason about them, and plan around them. The LLM call is not a function call. It is a relational operator, subject to the same cost-based decisions as joins and filters.
This enables two optimizations invisible to black-box approaches. Logical compression reduces natural language prompts to their essential components and deduces relational constraints the semantic operator must satisfy — constraints that can be pushed down to filter rows before the LLM ever sees them. Adaptive query execution dynamically reorders operators at runtime: if a cheap filter eliminates 90% of rows, apply it before the expensive semantic classification, not after. The LLM sees fewer rows, the query runs faster, token cost drops.
The result: 2-10x speedup over baseline systems on classification, summarization, and extraction tasks, with competitive result quality.
The deeper point is about what counts as a database operation. Relational algebra was defined around set operations — selection, projection, join, aggregation. For decades, these were the only verbs the optimizer understood. Sema adds a new verb: “understand what this text means.” And it turns out the optimizer's existing machinery — cost estimation, operator reordering, predicate pushdown — transfers directly. Understanding meaning is just another operation with a cost, a selectivity, and a position in the execution plan.