SQL is an intermediate representation, not a language for humans. The shift is from SQL as interface to SQL as compile target, with the semantic layer as the new authoring surface.
SQL is not a language. It is a contract.
At its core, SQL does one thing: it expresses how to retrieve and transform data in a structured system. It is declarative, optimised by engines, portable across systems, and deeply embedded in infrastructure. Databases understand it. Query planners optimise it. Execution engines run it.
SQL is not just syntax. It is the contract between intent and execution. That is why it never dies.
Humans were never meant to scale on SQL
While SQL is powerful, it has always had a hidden cost: humans use it to encode meaning. Look at one line:
SUM(CASE WHEN status = 'active' THEN amount END)Inside that single fragment lives what "active" means, what counts as "amount", which records qualify, and which business logic applies. SQL becomes a container for semantics. And over time, definitions drift, logic duplicates, queries diverge, meaning fragments. The system works. The organisation does not share a consistent understanding.
The real shift is already happening
Something subtle is changing in the wild. Fewer people are writing raw SQL. Instead:
- analysts use semantic models
- BI tools generate queries
- dbt compiles transformations
- LLMs generate SQL from prompts
SQL is still there. It is increasingly generated, not authored. This is not accidental. It is architectural.
SQL is becoming an intermediate representation
In compiler design, an intermediate representation (IR) is the layer between high-level intent and low-level execution. Humans do not write IR. Machines generate and optimise it.
This is exactly where SQL is heading. Instead of being the primary interface, SQL becomes the output of semantic systems, the execution layer for intent, and the bridge between reasoning and data engines. The flow becomes:
intent → semantics → SQL → execution
Not:
human → SQL → guess → iterate
Natural language alone is not enough
It is tempting to think LLMs will replace SQL entirely. Just ask questions. Get answers. But natural language has a problem: it is ambiguous.
- "What is revenue?"
- "Show active users"
- "Give me churn trends"
Without structure, those questions can be interpreted many ways. LLMs can generate SQL, but without a grounding layer, they guess joins, assume definitions, miss constraints, and ignore context. They sound correct. They are often wrong.
What is a semantic layer (and why it now matters)
A semantic layer is a typed, versioned representation of business meaning that sits between data sources and any system that asks questions of them. It defines entities, metrics, relationships, constraints, and policy in one place, so that natural-language questions, BI tools, copilots, and AI agents resolve to the same definitions before any SQL is written.
This is why the semantic layer becomes the new authoring surface. Instead of writing SQL, you define:
- entities (customer, subscription, order)
- metrics (revenue, churn, margin)
- relationships (ownership, dependency, causality)
- constraints (valid transformations, thresholds)
- context (persona, region, tenant)
When a question is asked, the system does not guess. It resolves intent through the semantic graph and then compiles SQL.
SQL as a compilation target
In this architecture, SQL is not the starting point. It is the end point. Optimised automatically. Consistent across queries. Aligned with semantic definitions. Governed by constraints. Invisible to most users.
Just like machine code: nobody writes assembly anymore unless they have to. Fewer people will write raw SQL over time. Not because SQL disappears, but because it moves down the stack.
The future stack
The emerging stack has four layers, each with a clear role and each more specialised than what came before.
Each layer specialises. Each gets sharper. SQL stops being the interface and becomes the bridge.
Where Colrows fits
This is the architecture Colrows was built for. Colrows separates two concerns: semantic reasoning (what the business means) and execution (how queries run).
When a user or agent asks a question, intent is interpreted using the semantic layer; definitions, constraints, and context are resolved at compile time; SQL is generated as a compiled output, dialect-perfect for the target engine; and execution happens on the underlying data system. The result: consistency of meaning, correctness of queries, compile-time governance, and flexibility of execution. SQL becomes an implementation detail, not the interface.
What this means for data engineers
This shift changes the role of data engineering. Less time writing queries. More time defining systems of meaning.
Instead of crafting complex SQL, debugging joins by hand, and aligning definitions manually across teams, the focus moves to modelling entities and relationships, defining metrics and constraints once, capturing business logic explicitly in the semantic graph, and enabling systems to generate the queries correctly.
It is a move from query engineering to knowledge engineering.
SQL will not die
SQL is too deeply embedded, too optimised, too widely supported, too fundamental to execution engines. It will remain the backbone of data systems - but its role will change. It will move from human interface to machine-generated intermediate layer.
For decades we treated SQL as the primary interface to data. It was never designed to carry the full weight of enterprise meaning. We are finally separating concerns:
- Meaning lives in semantics.
- Execution lives in engines.
- SQL connects the two.
That is why SQL will not die. It will quietly step out of the spotlight and become what it was always meant to be: a bridge, not the destination.
