What Is LookML Used for in Looker?

Emily Winks

Data Governance Expert

Updated:08/11/2026

Published:08/11/2026

14 min read

Watch Context Layer Live Get the Context Layer Ebook

Key takeaways

LookML defines dimensions, measures, and joins as version-controlled code inside Looker.
Looker's own testing found LookML cuts gen-AI query errors by up to two-thirds versus raw tables.
LookML predates dbt's Semantic Layer by about a decade as an early semantic layer as code.
LookML's biggest limitation: definitions do not travel if a team ever leaves Looker.

What is LookML used for in Looker?

LookML is Looker's language for defining metrics, dimensions and measures, and table relationships once, as version-controlled code, instead of re-deriving them in every query across dashboards. It groups those definitions into views, joins them into Explores, and groups related Explores into models that control what each team sees. Looker's SQL generator then turns that model, combined with a user's Explore selections, into the SQL that actually runs against the warehouse, so every report pulls from the same governed definition.

Core components:

Views definitions of dimensions and measures mapped to warehouse columns
Explores queryable models assembled from views through joins
Models groupings of Explores exposed through Looker's interface
Persistent Derived Tables pre-computed tables for expensive joins and aggregations
Git-based version control change review for metric definitions, the same as application code

See how ready your context layer is

Assess Context Maturity

LookML is the modeling language Looker uses to define dimensions, measures, and relationships as version-controlled code that your team’s queries inherit automatically, and Atlan is the context layer that connects those definitions back to warehouse lineage once they leave Looker. Looker launched LookML in 2012, and according to Google Cloud’s own internal testing, LookML-governed queries cut gen-AI natural-language query errors by as much as two-thirds compared with querying raw warehouse tables directly. This piece covers what LookML actually does, how it stacks up against newer semantic-layer-as-code tools like dbt and Cube, and where practitioners say it falls short.

LookML predates most of the vocabulary now used to describe it. Looker built the language in 2012 to solve one specific problem: analysts kept writing the same metric five different ways in five different queries, and nobody could tell which version was correct.

A modeling language, not a BI tool. LookML lives inside Looker, not a separate product you buy or install.
Version-controlled by default. LookML files live in Git, so a metric’s definition goes through the same review process as application code.
Translated into SQL at query time. Looker’s SQL generator turns a LookML model, plus a user’s selections, into the query that runs.
An early “semantic layer as code.” LookML shipped roughly a decade before dbt’s Semantic Layer and Cube popularized that exact phrase.

Field	Content
What it is	The language Looker uses to define semantic data models, dimensions, measures, and relationships, as version-controlled code (Google Cloud)
Key benefit	Looker’s internal testing found LookML-governed queries cut gen-AI data errors by as much as two-thirds versus raw tables
Best for	Teams standardizing metric definitions across Looker dashboards and Explores
Origin	Launched with Looker in 2012, about a decade before dbt revamped its own Semantic Layer with MetricFlow at Coalesce 2023
Core components	Views, dimensions, measures, joins, Explores, models, Persistent Derived Tables

One context layer, every metric definition

LookML is one of several places a metric definition lives today. The AI Context Stack shows where semantic layers like LookML fit relative to the warehouse, the catalog, and the agents querying both.

Get the AI Context Stack

What is LookML?

LookML is Looker’s modeling language for turning raw tables into reusable dimensions, measures, and relationships. According to Google Cloud’s own documentation, LookML is “the language that is used in Looker to create semantic data models,” used to describe dimensions, aggregates, calculations, and data relationships in a SQL database.

That definition matters more than it sounds like it should. A dimension is a column or a simple transformation of one, something you can group by. A measure is an aggregation, a sum, count, or average, computed across rows. LookML separates the two explicitly, which is the mechanical reason a LookML model stays consistent no matter which Explore or dashboard queries it.

LookML files live in Git, and teams review and version changes to them the same way they would a pull request against application code. That is the DRY principle (don’t repeat yourself) applied to metric definitions: write the calculation once, in one file, and every query that needs it references the same source instead of re-deriving it.

One scope note worth settling early: LookML is not Looker Studio, the separate, free Google reporting tool formerly called Google Data Studio. The naming overlap causes real confusion, and it comes up again in the FAQ below. LookML’s actual counterpart is the semantic layer concept itself, not any particular reporting front end.

LookML answers “what does this metric mean” once, inside Looker. It does not answer what happens when a dbt model, a spreadsheet, and a Looker Explore all claim to define the same number differently, a scope limit worth keeping in mind for the rest of this explainer.

How does LookML work in Looker?

LookML works by translating version-controlled model files into the SQL that Looker’s Explore interface runs against the warehouse. Three LookML object types do the actual work: views, Explores, and models.

1. Views: dimensions and measures

A LookML view defines the individual fields, dimensions and measures, that map to columns or calculations on an underlying table. One view typically corresponds to one table or one well-defined slice of a table, and it is where a metric’s actual formula lives, once, instead of once per report.

2. Explores: joins and the SQL generator

An Explore assembles one or more views into a queryable model through joins, and it is what a business user actually opens inside Looker. According to Jessica Talisman (2026), Semantic Engineer and Information Architect: “Looker’s LookML is a proprietary declarative modeling language that defines dimensions, measures, and joins… when a user interacts with the Explore UI, Looker’s SQL generator translates the LookML model plus user selections into SQL.” That translation step, LookML plus user clicks in, real SQL out, is the entire mechanism.

3. Models and Persistent Derived Tables

Models group related Explores together and control which ones a given team or role can see. Persistent Derived Tables (PDTs) pre-compute expensive joins or aggregations so a dashboard does not re-run the same heavy query on every load, a benefit covered in more depth below.

Aspect	Ad hoc SQL reporting	LookML semantic modeling
Metric definitions	Redefined in every query or dashboard	Defined once, reused across every Explore
Version control	Rarely tracked	Git-based, version-controlled by default
Consistency	Prone to drift between reports	Enforced through shared views and models
Governance	Manual review, if any	Centralized in LookML files
AI/agent readiness	Raw tables only, error-prone for natural-language queries	Cuts gen-AI query errors by up to two-thirds (Google Cloud, 2025)

How LookML turns warehouse tables into a Looker semantic model: raw warehouse tables flowing into LookML views with dimensions and measures, then Explores with joins, then BI output for business users

A LookML semantic model turns raw warehouse tables into reusable views and Explores so every BI output is built on consistent, governed definitions. Source: Atlan.

The mechanism itself is genuinely well designed: one file, reviewed like code, drives every query downstream of it. What it cannot do on its own is tell a reader whether that same metric is defined the same way in the other tools their organization also runs on top of the same warehouse tables.

Is LookML a semantic layer?

Independent practitioners credit LookML as one of the earliest mainstream implementations of “semantic layer as code,” roughly a decade before that exact phrase attached itself to dbt and Cube. According to Definite (2026), LookML “pioneered the ‘semantic layer as code’ approach” that later tools would popularize under a new name.

A second, independent source agrees on the timeline. According to Strategic Tensors (2026), “Looker pioneered ‘semantic layer as code’ with LookML over a decade ago,” years before dbt’s Semantic Layer or Cube existed as products.

Google has not stood still on the critique, either: it has since shipped Looker Modeler, an early attempt to decouple LookML’s semantic layer from the Looker BI interface, though Definite notes adoption is still early.

Tool	Origin	Approach
LookML (Looker)	Around 2012	Semantic layer defined as version-controlled code inside the BI tool
dbt Semantic Layer / MetricFlow	Revamped with MetricFlow, unveiled at Coalesce 2023	Semantic layer as code, decoupled from any single BI tool

Cube was founded several years after LookML (exact date unconfirmed here). Readers who want the fuller three-way breakdown of how LookML, Lightdash, and the dbt Semantic Layer compare against a governed context layer can find it in a dedicated comparison.

LookML earned the “semantic layer as code” label roughly a decade before the rest of the industry started using that phrase. The label does not change the underlying trade-off: an early semantic layer is still a semantic layer locked inside one BI tool.

Same metric, five different answers?

If LookML, dbt, and a dashboard tool define the same metric three different ways, the Context Gap Calculator shows how much that drift is actually costing your team.

Try the Gap Calculator

What are the benefits of using LookML?

LookML’s main payoff is consistency: one definition of a metric that every Explore and dashboard inherits, plus measurable gains in query performance and AI accuracy. Instead of a metric getting redefined slightly differently in ten dashboards, it gets defined once, reviewed once, and reused everywhere.

That consistency has a measurable AI accuracy benefit, too. According to Richard Kuzma and Jesse Sherb (Google Cloud, 2025), Looker’s internal testing found that its semantic layer reduces data errors in gen-AI natural-language queries by as much as two-thirds compared with letting a model query raw, ungoverned tables directly.

Third-party analysts have taken notice of the broader pattern. According to Sean Zinsmeister and Karthik Ramakrishnan (Google Cloud, 2026), Google Cloud was named a Leader in the Gartner Magic Quadrant for Analytics and BI Platforms for the third consecutive year in 2026, with LookML’s code-based, Git-versioned semantic layer cited as a core reason.

Persistent Derived Tables (PDTs)

PDTs answer a narrower but practical question: what happens when the “one definition, reused everywhere” model gets expensive to compute? A PDT pre-computes a heavy join or aggregation once and stores the result, so every dashboard that needs it reads a cached table instead of re-running the same costly query. That is a real performance win, not just a governance one, and it is part of why LookML models scale to dashboards with hundreds of concurrent users.

Every benefit above traces back to the same root cause: one definition, reused everywhere, inside Looker. That is a genuine win for consistency and for AI agent accuracy, and it is also exactly the boundary the next section runs into.

What are the limitations of LookML, and when should you look beyond it?

LookML’s two most-cited practitioner complaints are a real learning curve on top of SQL, and definitions that do not travel if a team ever leaves Looker. Neither complaint is about LookML doing its job badly; both are about where that job’s boundary sits.

On the learning curve: according to Holistics.io (2024), Looker offers “flexible and sophisticated access control but quite complex with high learning curve,” because LookML adds a modeling layer, views, Explores, joins, dimensions, measures, on top of SQL instead of replacing it. A named practitioner puts the maintenance side of that same complaint plainly. According to Reed Rawlings (Sigma Computing, 2023), Enterprise Solutions Engineer: “Wow, LookML is pretty neat, but I’m worried about maintaining an entire code base just for analytics.”

The lock-in complaint is the second, more consequential theme. According to a practitioner on r/BusinessIntelligence (2024), a team needs “semantic definitions to be available throughout our data ecosystem, including rETL processes, machine learning pipelines, and SQL access,” not locked inside one BI platform. A head-to-head comparison from Omni, a Looker competitor, states the same concern more bluntly: if a team ever leaves Looker, its LookML investment does not travel with it. Worth reading that framing as an interested competitor’s pitch rather than a neutral fact, since Omni is selling an alternative.

What this adds up to in practice: LookML fits teams who live inside Looker end to end, where “semantic layer defined inside the BI tool” is a feature, not a constraint. Teams that need that same metric definition to travel to another BI tool, a reverse-ETL pipeline, or an AI agent querying the warehouse directly are the ones who feel the lock-in most, which is exactly the gap common context problems across the data stack describes at a broader scale.

None of this means LookML is poorly designed. It means LookML was built to solve definition drift inside Looker, not definition drift across the rest of the stack, which is a different problem with a different fix.

How Atlan approaches LookML

Atlan sits underneath LookML and every other semantic layer a team runs, cataloging what already exists instead of asking anyone to model a metric a second time. Atlan has a live Looker connector that catalogs Explores, dashboards, models, views, folders, and tiles, and it crawls the underlying LookML files to resolve lineage, confirming that a table referenced inside a LookML model is the same physical table Atlan already tracks from a Snowflake or BigQuery connection.

In practice, that means a LookML measure’s definition, and its lineage back to the raw columns it draws from, become visible in the context layer that sits across LookML, dbt, and every other tool with its own opinion about what a metric means. LookML is well-designed for what it does inside Looker. Atlan’s job is narrower: making that definition, and how it relates to what other tools call the same number, visible outside Looker too.

See Looker metadata in the context layer

Watch how Atlan catalogs Looker Explores, dashboards, and LookML models, then connects each one back to the warehouse tables and other tools that define the same metric.

Watch a Live Demo

LookML solved definition drift inside Looker, not everywhere else

LookML did exactly what it was built to do in 2012: give one team, inside one BI tool, a single, version-controlled place to define what a metric means. A decade of practitioner complaints, and a decade of newer “semantic layer as code” tools, point at the same edge of that design: a LookML measure is trustworthy inside Looker and invisible everywhere else.

That is the same fragmentation this whole category keeps running into. dbt’s Semantic Layer, Cube, and Lightdash each solve “define it once” inside their own walls, and none of them know what the others call the same number. A context graph underneath all of them, not another semantic layer competing for the same job, is what turns five disconnected definitions back into one traceable answer.

Book a Demo

FAQs about LookML

1. Is LookML based on SQL?

LookML is not SQL itself, it is a modeling layer that sits on top of SQL. LookML defines dimensions, measures, and joins in a declarative syntax, and Looker’s SQL generator translates those definitions, plus a user’s Explore selections, into the SQL query that runs against the warehouse.

2. What is a LookML dashboard?

A LookML dashboard is a Looker dashboard built from LookML-defined Explores rather than assembled ad hoc. Because every tile pulls from the same underlying LookML model, the dimensions and measures stay consistent across tiles, and a change to a metric’s definition propagates to every dashboard that uses it.

3. What is the difference between Looker and LookML?

Looker is the business intelligence platform, the application analysts open to explore data and build dashboards. LookML is the modeling language inside Looker that defines what the data means: the dimensions, measures, and relationships that Looker’s Explore interface and SQL generator rely on.

4. Is LookML a programming language?

LookML is a domain-specific, declarative language, not a general-purpose programming language like Python or Java. It describes what a data model looks like, its fields, joins, and relationships, rather than a sequence of instructions, and it has no loops or functions of its own.

5. Can I use LookML with Looker Studio?

No. Looker Studio, formerly Google Data Studio, is a separate, free reporting tool from Google that does not read or write LookML. LookML only exists inside Looker, the enterprise BI platform Google acquired in 2019, and the two products share a name prefix but not a modeling layer.

6. How does LookML improve data governance?

LookML improves governance by centralizing metric definitions in version-controlled files instead of letting every dashboard redefine a calculation independently. Changes go through Git review like application code, so a team can see who changed a metric’s definition, when, and why before it reaches production reports.

7. Is LookML difficult to learn?

Yes, most practitioners describe a real learning curve, even for people who already know SQL well. LookML adds its own modeling concepts, views, Explores, joins, dimensions, and measures, on top of SQL rather than replacing it, so new users are learning a second layer, not swapping one language for another.

Sources

Share this article

Atlan is the Context Layer for AI, a Leader in the Gartner Magic Quadrant for D&A Governance (2026) and the Forrester Wave for Data Governance (Q3 2025). Atlan unifies your data, business knowledge, and the meaning behind your metrics into one Enterprise Data Graph that gives every team, and every AI agent, the trusted context it needs. Trusted by Mastercard, Workday, General Motors, CME Group, HubSpot, FOX, Virgin Media O2, Elastic, and 400+ enterprises.

Book a Demo Context Studio Live