LookML vs a Universal Semantic Layer: What Changes

---

LookML defines every dimension, measure, and join a Looker analyst sees, version-controlled and reviewed like application code, which is why Looker’s own testing found it cuts gen-AI query errors by up to two-thirds versus querying raw warehouse tables. That model does travel further than it used to: Google’s Open SQL Interface exposes LookML over JDBC to Tableau, ThoughtSpot, Power BI, Looker Studio and Excel, and a Looker-managed MCP server in Preview serves agent clients directly. What stays constant is that Looker authors and compiles the model, and the JDBC route requires a BigQuery connection. A universal semantic layer, Cube, the dbt Semantic Layer, or AtScale are the three names that come up in almost every evaluation, solves a related but distinct problem: define a metric once and serve it to whichever tool asks, Looker included. Atlan sits above either choice as the context layer, attaching lineage, ownership, and access policy to whatever semantic layer a team already runs. This page assumes you already know what LookML does inside Looker; it answers the question that comes after: does a second BI tool or an AI agent asking for the same number change what you should model in.

---

LookML vs a universal semantic layer: what’s the difference?

The distinction holds regardless of which universal option a team picks: LookML governs what a metric means for Looker’s own consumers, and a universal semantic layer governs what it means for consumers that were never modelled in a BI tool at all. Looker shipped LookML to stop analysts from redefining the same calculation five different ways across five dashboards, and it succeeded at exactly that scope. Google has since widened the exit: its own page for the semantic layer is headed “Ground your AI in truth with Looker’s open semantic layer.”

Cube, the dbt Semantic Layer, and AtScale start from the other side of that line, each from a different entry point. Cube ships an open-source core, MIT for the client and Apache 2.0 for the backend, and serves SQL, DAX, REST, and GraphQL from one definition. The dbt Semantic Layer, rebuilt around MetricFlow at Coalesce 2023 when dbt deprecated the older dbt_metrics package, keeps definitions in the same Git-reviewed YAML dbt engineers already own. AtScale takes the opposite entry point: a universal semantic layer built for the Excel and Power BI estates that predate the modern warehouse. What separates the three from LookML is not whether a second tool can read the model. It is who owns the modelling language, and whether the answer depends on one vendor’s warehouse and one vendor’s interface.

---

What is LookML?

LookML is the language Looker uses to define dimensions, measures, and joins once, in version-controlled files, so every Explore and dashboard inherits the same definition. Google’s documentation calls it “the language that is used in Looker to create semantic data models,” and it worked this way years before “semantic layer as code” became the industry’s phrase for it. A field guide to semantic layers covers the broader category; the shorter version is that LookML answers “what does this metric mean” once, with Looker as the authoring and compilation engine.

The trade-off sits in that last clause. A team whose only BI interface is Looker never thinks about it. A second consumer can reach the model, over JDBC or over MCP, but the route runs through Looker, and the JDBC route only works if the LookML project connects to BigQuery. A reverse-ETL pipeline or an agent hitting the warehouse on its own path gets neither.

Core components of LookML

• Views: dimension and measure definitions mapped to warehouse columns
• Explores: views assembled through joins into the models analysts open
• Models: groupings of Explores that control what a team or role sees
• Persistent Derived Tables: pre-computed results for expensive joins
• Git-based version control: every metric change reviewed like application code

---

What is a universal semantic layer?

A universal semantic layer defines a metric once, in code or configuration, and serves that definition over an API any BI tool, embedded product, or AI agent can call, rather than confining it to one platform’s interface. Semantic layer for analytics covers the mechanics in more depth; the property that matters for this comparison is portability, not modeling syntax.

Cube’s documented architecture covers that job in four parts: data modeling in YAML, JavaScript, or Python; access control enforced at the semantic layer itself; a caching layer with Cube Store for sub-second queries; and a multi-API surface spanning SQL, DAX, REST (JSON), GraphQL, and an MCP server built for AI agents. The dbt Semantic Layer keeps that same job inside the dbt project analytics engineers already review in pull requests, and helped anchor Open Semantic Interchange, a vendor-neutral format for moving definitions between tools without a rewrite. That initiative has since entered the Apache Incubator as Apache Ossie, is backed by more than 50 organisations including Cube, AtScale, dbt Labs, Snowflake and Atlan, and dbt v1.12 and higher parse Ossie documents from an osi/ directory. AtScale rounds out the shortlist for teams with a large Excel and Power BI estate that needs one governed metric definition. The same choice shows up one layer down the stack: Unity Catalog’s semantic layer and Snowflake Semantic Views both trade warehouse-native convenience for the same portability gap, one warehouse over.

Core components of a universal semantic layer

• Vendor-neutral modeling: metrics defined in YAML, SQL, or a DSL that isn’t tied to one BI vendor’s interface
• Multi-protocol serving: SQL, DAX, REST, and GraphQL from a single definition, depending on the vendor
• Cross-tool consistency: the same metric returns the same value in every connected BI tool, app, or agent
• Open Semantic Interchange alignment: an emerging, vendor-neutral export format several of these tools now support

---

LookML vs a universal semantic layer: head-to-head

The sharpest differences show up in reach, not modeling quality. LookML’s model is more mature inside its own scope; a universal semantic layer trades some in-platform polish for a query surface that works everywhere.

Example: an AI copilot that needs Looker’s number without Looker’s interface. A team building an agent to answer “what was Q3 revenue” faces this exact fork. If the agent only ever asks Looker, LookML’s own definition is a complete answer, provided AI agent governance already covers who that agent may ask on behalf of. The moment the same agent also needs a number a Tableau dashboard or a Snowflake Cortex Analyst session produced, LookML has nothing to say about whether those numbers agree. The Open SQL Interface exports LookML’s definition; it does not adjudicate it against a competing one.

---

Do you need to replace LookML with a universal semantic layer?

Most teams that ask this question don’t need to replace anything. They need the two to work together: LookML stays the interface analysts already know, and a universal layer handles everything LookML can’t reach.

How they work together

Google’s own seam is the Open SQL Interface: third-party tools connect to a LookML model over JDBC as if it were a database, provided the project runs on a BigQuery connection. Short of that, teams typically keep LookML as the system of record for Looker dashboards and add Cube or the dbt Semantic Layer underneath for everything Looker doesn’t touch: an embedded analytics product, a second BI tool after an acquisition, or an AI agent harness that needs to query metrics directly. Context layer vs semantic layer covers the layer above both: neither records who owns a metric or whether the requesting agent may see it, a governance question, not a modeling one.

The MCP Server delivers that governed context the same way regardless of which semantic layer sits underneath, the same pattern how to implement an enterprise context layer for AI walks through for a data catalog or any other data infrastructure an AI program depends on.

---

When should you add a universal semantic layer on top of LookML?

The right call depends on how many consumers need the same metric, not on whether LookML is doing its job well inside Looker.

Stay with LookML alone when Looker is the only BI interface your organization runs, every dashboard and Explore lives inside it, and no other tool or agent needs to query the same warehouse tables directly.

Add a universal semantic layer when a second BI tool enters the stack (common after an acquisition), an embedded analytics product needs metrics served over an API, or metrics have to reach a warehouse on a connection LookML’s JDBC route does not cover. This is the same single-stack lock-in tradeoff that shows up whenever one vendor’s format becomes the only place business logic lives.

Add a governed context layer regardless of which semantic layer you pick when more than one agent needs to cite the same metric, or why AI agents fail in production starts to look less like a model problem and more like a definition problem.

---

How Atlan approaches LookML and universal semantic layers

Atlan sits underneath whichever semantic layer a team runs, cataloging what already exists instead of asking anyone to model a metric a second time. A live Looker connector catalogs Explores, dashboards, models, views, and folders, and crawls the underlying LookML files to resolve lineage back to the physical warehouse tables already tracked from Snowflake, BigQuery, or any other source. Where a team runs a universal semantic layer instead, dbt Semantic Layer definitions are ingested natively and enriched with ownership, lineage, and quality signals the semantic layer itself doesn’t carry.

Either path lands in the same place: core components of a context layer sit above LookML, Cube, or the dbt Semantic Layer alike, resolving what context engineering actually requires, a definition plus who’s accountable for it. A context graph connects a LookML measure to the same governance metadata a Cube or dbt metric carries, so one agent gets a consistent answer no matter which semantic layer produced the number. MCP delivers that context to any agent framework, and in the AI Labs benchmark, adding it improved text-to-SQL accuracy by 38%, independent of which semantic layer a team runs.

---

Real stories from real customers: One shared vocabulary across tools

Neither account names LookML or a specific universal semantic layer. Both arrive at the same point this comparison keeps circling back to: the modeling language underneath was never the bottleneck once more than one tool, or more than one agent, needed to agree on what a number meant.

---

The lock-in question a universal semantic layer alone doesn’t answer

LookML answers what a metric means for Looker’s consumers, with years of production maturity behind that one job. A universal semantic layer answers the same question across every tool that might ask, at the cost of the deep, single-platform polish LookML has. Neither answers a third question an agent actually needs settled: who owns this number, and is the agent asking allowed to see it. Teams that treat “LookML or Cube” as the whole decision tend to ship a portable metric nobody is accountable for, a governance gap no modeling language was built to close on its own.

---

FAQs about LookML vs a universal semantic layer

1. Is LookML a universal semantic layer?
   No. LookML is authored and compiled inside Looker, and Google’s own routes out of it, the Open SQL Interface over JDBC and the Looker-managed MCP server, run through Looker. A universal semantic layer is built independently of any BI tool and serves the same kind of definition over SQL, DAX, REST, or GraphQL to whichever tool or AI agent asks.

2. Can LookML metrics be reused outside Looker?
   Yes, through two documented routes. The Open SQL Interface exposes LookML models over JDBC to third-party applications, and Google’s docs name Tableau, ThoughtSpot, Power BI, Looker Studio and Excel; the LookML project must use a BigQuery connection. The Looker-managed MCP server, in Preview, lets agent clients query LookML models directly under the user’s Looker roles. What does not travel is the LookML source itself, which only Looker compiles.

3. What is a universal semantic layer, with examples?
   It defines a metric once and serves it to every consumer that queries it, across BI tools, embedded analytics, and AI agents, rather than inside one BI platform. Cube, the dbt Semantic Layer, and AtScale are the three most evaluated examples.

4. Is Cube a replacement for LookML?
   Not usually. Teams committed to Looker as their BI interface tend to keep LookML for what analysts see, and add Cube (or another universal layer) underneath once a second tool, an embedded product, or an agent needs the same metric outside Looker.

5. Does a universal semantic layer solve AI agent governance on its own?
   No. It solves definition drift: the same metric, computed the same way, everywhere. It doesn’t, by itself, record who owns that metric or whether the requesting agent may see it. That’s a separate, governance-layer question.

6. How does Atlan work with LookML or a universal semantic layer?
   Atlan catalogs LookML models, Explores, and dashboards directly, and ingests definitions from a universal semantic layer like the dbt Semantic Layer. Either way, Atlan adds lineage, ownership, and access policy, then delivers that context to AI agents through its MCP Server.

---

Sources

1. Introduction to LookML, Google Cloud
2. How Looker’s semantic layer enhances gen AI trustworthiness, Google Cloud Blog
3. Open SQL Interface, Google Cloud
4. Looker MCP server, Google Cloud
5. Looker’s open semantic layer, Google Cloud
6. Deprecating dbt_metrics and the legacy Semantic Layer, dbt Labs
7. Apache Ossie semantic models, dbt Labs
8. Open Semantic Interchange
9. Apache Ossie (Incubating): The New Name for Open Semantic Interchange, Apache Ossie
10. Cube documentation
11. cube-js/cube, GitHub
12. Universal Semantic Layer, AtScale