Data Modeling Languages: Query & Semantic Layer Evolution

Data modeling languages or query languages. Languages above SQL.

What will be interesting, is the language we use for defining these metrics. It started with MDX, then DAX, then later came LookML and now we have Malloy and others:

gantt
    title Analytics & Semantic Query Languages Timeline
    dateFormat YYYY
    axisFormat %Y
    section Foundation
    SQL / SEQUEL — IBM          : milestone, 1974, 0d
    section OLAP / Cube Languages
    MDX — Microsoft             : milestone, 1997, 0d
    DAX — Microsoft             : milestone, 2009, 0d
    MAQL — GoodData             : milestone, 2009, 0d
    section Graph Query Languages
    Gremlin — Apache TinkerPop  : milestone, 2009, 0d
    Cypher — Neo4j              : milestone, 2011, 0d
    section BI Platform DSLs
    LookML — Looker             : milestone, 2012, 0d
    TML — ThoughtSpot           : milestone, 2020, 0d
    Malloy — Lloyd Tabb         : milestone, 2021, 0d
    TMDL — Microsoft            : milestone, 2023, 0d
    Open SQL — Looker           : milestone, 2024, 0d
    Metrics SQL — Rill          : milestone, 2025, 0d
    Semantic SQL — Coginiti     : milestone, 2025, 0d
    E-Graph SQL — Cube          : milestone, 2026, 0d
    section SQL Alternatives & Extensions
    Apache Calcite — Julian Hyde : milestone, 2014, 0d
    Ibis                        : milestone, 2015, 0d
    KQL — Microsoft             : milestone, 2015, 0d
    Morel — Julian Hyde         : milestone, 2019, 0d
    Substrait                   : milestone, 2021, 0d
    PRQL                        : milestone, 2022, 0d
    Trilogy / pytrilogy         : milestone, 2023, 0d
  

• 1974: SQL - originated as SEQUEL at IBM.
• 1997: MDX (MultiDimensional eXpressions) - First major query language for OLAP cubes by Microsoft
• 2009: DAX (Data Analysis Expressions) - By Microsoft for PowerPivot/PowerBI
• 2009: Gremlin Query Language - Gremlin was created in 2009 by Marko Rodriguez as part of the TinkerPop project (which later became Apache TinkerPop, entering the ASF incubator in 2015).
• 2009: MAQL: Multidimensional Analytical Query Language (MAQL) is GoodData’s proprietary querying language.
• 2011: Cypher query language for graph databases such as Neo4j
• 2012: LookML - By Looker for their BI platform
• 2020: ThoughtSpot TML
• 2021: Malloy Language - By Malloy (ex-Looker team)
• 202X: HexQL - By Hex Technologies
• 2023: Tabular Model Definition Language (TMDL)
• 2025: Metrics SQL by Rill
• 2025: Coginiti Semantic SQL: A SQL dialect supported by the Coginiti semantic layer.
• 2026: SQL with E-Graph (Cube, see below )

Additional to Add

Suggested one to add: GQL, JOOQ, TaxiQL, SPARQL, Cypher

These are related and alternatives to plain SQL data modeling languages:

• 2010/2014 - Apache Calcite (Extending SQL for analytics): Originally “Optiq” by Julian Hyde; SQL parsing/planning framework that underpins many modern query engines (Flink, Hive, Druid, Avatica/JDBC). Donated to Apache in 2014. Note: Julian Hyde is also the Morel author.
• 2015 - Ibis: By Ibis project for DataFrame operations by Wes McKinney
• 2015 - Kusto Query Language (KQL): By Microsoft, pipeline-style query language for telemetry/log analytics; first public via Application Insights (2015), GA with Azure Data Explorer (2018). Now spans Azure Monitor, Sentinel, Fabric.
• 2019 - Morel Language: Based on ideas around Datalog by Julian Hyde. (More general modeling: MiniZinc) - 2019 was first commit on GitHub.

  • It is a good language for ETL IMHO but until it has measures & dimensional calculations I couldn’t call it a BI language. There are some design sketches here. Julien says

• 2021 - Substrait: Cross-platform query serialization
• 2022 - PRQL (Pipelined Relational Query Language): Open source SQL alternative
• 2023/2024 - Trilogy / pytrilogy: Higher-level composable SQL that compiles to SQL; replaces joins/table refs with a semantic binding layer (.preql files).
• 2024 -Looker Open SQL: A JDBC/SQL interface over LookML models; marks the shift from “learn our semantic DSL” to “query our semantic layer with standard SQL”

They are usually used or needed in OLAP Cubes or a Semantic Layer.

• 1994/96: UML

See Data Model Engine.

More on Metrics Layer and Metrics SQL. Also interesting in relation to Extending SQL for analytics.

Related and interesting: Julian Hyde is trying to Extending SQL for analytics with more analytical MDX-like capabilities.

Julian says 2026-05-23:

Regular SQL has a major problem for analytics: it is not powerful enough to define measures. Most attempts to add measures to SQL produce a SQL-like language with inconsistent semantics; with “Measures in SQL” I believe we fixed it. Tweet

Measure in SQL is a whitepaper by Julien and John Fremlin, see Measures in SQL.

Cube and Artyom Keydunov dabbled into this in 2026 and used plain old SQL - his assement:

We looked hard at the alternatives. MDX is effectively dead. DAX lives only inside Microsoft. REST/GraphQL APIs force every tool to learn a proprietary interface. A new purpose-built DSL is theoretically cleaner — but no AI agent knows it.

SQL wins for one reason: every database, every BI tool, and every LLM already speaks it.

Similar to what Rill is betting on for their Metrics SQL.

Artyom continues with the downsides of SQL:

But regular SQL has a problem. It evaluates bottom-up — subqueries first, outer query last. OLAP measures need the opposite. A ratio like revenue_per_user isn’t a column you can select; it’s a computation that depends on the grouping of whatever query wraps it.

That’s what MEASURE() does. It carries the measure definition forward until the engine hits the first real aggregating query, and evaluates it there. One function, and the rest of the SQL surface stays intact. This is the unlock for agentic analytics. LLMs that struggle to write a correct metric from raw SQL can reliably use MEASURE(revenue) when handed a semantic layer to query against.

Full article at How Semantic SQL Works

Their solution is E-Graph. The MEASURE() seems very related from Whitepaper Measures in SQL. Also check out the dbt-cube integration at Cube.

SLayer:

When AI agents write raw SQL, they hallucinate column names, get joins wrong, and produce metrics that drift between queries. Existing semantic layers (Cube, dbt metrics) were built for dashboards — heavy infrastructure, slow model refresh cycles, and not enough flexibility for ad-hoc agent queries. SLayer

But I don’t agree with hallucinating column name has anything to do with SQL. You could just use a CLI or deterministic function that returns column names based on actual names 🤔

Egor Kraev, CTO of Slayer, makes the point:

We are going the opposite way with SLayer - defining an elegant DSL that allows especially agents to naturally express the queries, with way more flexibility than other semantic layers I know, yet way easier to read and audit than the corresponding SQL :)

Trying to squeeze semantic layer information into SQL is to me just putting another layer of duct tape on an already monstrous (if super powerful) machine.

Not sure I agree, but good to have the view of the other side.

As with the Whitepaper Measure in SQL, it’s Julian Hyde paper on extending SQL and overcome the challenges.

In my opinion, the challenge with natural language for semantic layers is that it’s too imprecise; that’s why SQL is better. E.g., if you say “next two weeks,” does that include today? When does it start, etc?

But I agree that having more context helps. How we define it must be as precise as possible, and I like it if that is declarative, where AI and humans can iterate. If you generate, you’re not sure if the output is then another state you need to manage.

• Query Interfaces for OLAP Systems: Great article comparing DAX vs. MDX and what Modern OLAP Systems can do with Metrics Layers in SQL: that takes SQL queries with measures as input and produces valid.
  • related to Extending SQL for analytics

Origin: Data Modeling
References: Data Modeling Techniques, Data Modeling Frameworks