Half the market is evaluating text-to-SQL against a semantic layer, as if it were a choice.
One turns language into a query. The other decides whether that query is allowed to mean what it says.
They operate at different layers
| Text-to-SQL | Semantic layer | |
|---|---|---|
| Responsibility | Parse intent, emit syntax | Resolve meaning, grain, joins, policy |
Knows what revenue means |
No | Yes, versioned |
| Knows which join is valid | Guesses | Proves |
| Knows who's asking | No | Yes, and compiles accordingly |
| Fails how | Confident wrong answer | Explicit refusal |
Buying the first without the second gets you fluent SQL over ambiguous meaning — which is the exact failure every enterprise pilot reports.
Why mature teams run both
The LLM is genuinely good at one thing: turning messy human phrasing into structured intent. That's real value and worth having.
What it's bad at is deciding what your business means — because that information was never in its training data and can't be fitted into a prompt.
So the mature architecture uses each for what it's good at: model handles language, graph handles meaning, planner handles joins, policy engine handles authorisation, compiler emits SQL.
The number that makes the case
Give the same model a resolved definition and a proven join and accuracy stops being a function of prompt quality. In our benchmark: 14.5% on raw schema, 98.2% with compiled context.
Take the semantic layer away and no model upgrade recovers that gap, because the missing information isn't in the model.
The evaluation question
Not "which one." It's whether the tool you're buying includes the substrate, or quietly assumes you already have one.
The full breakdown — the layer-by-layer division of responsibility, and how the two compose in production — is here:
👉 Semantic Layer vs Text-to-SQL: When Each Wins, and Why Mature Teams Use Both
Originally published at colrows.com/blogs/semantic-layer-vs-text-to-sql
Top comments (0)