GoKawiilSQL has been the lingua franca of data for over 40 years. We decided to make it the lingua franca of our metrics-based semantic layer too.
When we built Rill, we made a bet that metrics – concepts like revenue, MAU, ROAS — are the core primitive for semantic layers.
We also believed that querying a semantic layer (and its metrics) should not require learning a custom language or API. Instead, the semantic layer should speak SQL, the language every database, BI tool, and AI agent already knows.
This blog post is a deep technical dive into how Rill's Metrics SQL works, why we built it the way we did, and where we're taking it next.
Using SQL and metrics for a determistic, secure, and fast semantic layer
In a modern analytics stack, a business metric like revenue per active user needs to be defined in multiple places: a dbt model, a Looker Explore, a Metabase question, a Python notebook, a Slack bot and in your AI Agent metadata. Over time, each definition drifts from the others. When finance asks "why does your number not match mine?", the answer is usually "we're computing it differently."
The metrics layer concept — define business logic once, query it anywhere — has been around for years. But implementations consistently run into the same trap: they invent a new query language. GraphQL queries, proprietary MDX expressions, or JSON-over-REST APIs, each requires learning a new abstraction. Each breaks existing SQL tooling. Each becomes a barrier between business logic and applications.
Julian Hyde, one of the creators of Apache Calcite and a pioneer of the SQL ecosystem, argued in his Data Council talk that metrics need first-class SQL representation — not because SQL is perfect, but because it is universal: the one language every tool, every engineer, and every AI model already speaks. Julian proposed adding a first-class MEASURE semantics in SQL — where aggregates are declared as semantic objects, not inline expressions, and the database engine handles computing measures in the correct context.
That framing resonated and we built a metrics-first semantic layer queryable using SQL. Here is what that enabled:
A deterministic source of truth. Every consumer — dashboards, notebooks, APIs, AI agents — resolves a metric from the same governed definition. No copies, no drift. An agent querying the revenue metric returns the same answer every time, not an inferred expression on raw table schemas.
... continue reading