LookML is the proprietary data modeling language that powers Looker, Google Cloud's BI platform. It is, depending on who you ask, either the single most important innovation in BI of the last fifteen years or the original sin that locked an entire generation of metric definitions inside a closed-source vendor. Both are true.

LookML did one thing nobody had done seriously before: it made business metric definitions live in version-controlled code files, reviewed in pull requests, deployed through CI/CD, and maintained like software. Before LookML, metric definitions lived in Excel formulas, Tableau calculated fields, and the heads of senior analysts. After LookML, "revenue" was a measure: { type: sum, sql: ${TABLE}.amount ;; } line in a .lkml file in a Git repo, and changing it required a code review.

This is the original genius: applying software engineering hygiene to business intelligence. It is also the original sin: the file format is proprietary, the engine that runs it is proprietary, and once you have hundreds of LookML files, leaving Looker means rewriting your entire metric layer.

Origin Story

Looker was founded in 2012 in Santa Cruz, California, by Lloyd Tabb and Ben Porterfield. Tabb, who designed LookML, had been a database engineer at Borland (where he worked on dBase IV and Paradox), then a co-founder of LiveOps. He had spent twenty years watching analysts wrestle with the same problem: SQL queries were powerful but unsharable, and BI tools were sharable but unrigorous. The drag-and-drop GUIs of Tableau and the ad hoc SQL of Mode were two ways of making the same mistake — letting every analyst define metrics independently and then arguing about whose number was right.

Tabb's bet was that a code-first modeling layer could fix this. If you write your metrics in a real text file, in a real syntax, checked into Git, then there is exactly one definition of "active user," it gets reviewed before it changes, and every dashboard built in Looker uses the same one. He invented LookML as that file format.

LookML is roughly a YAML/Pascal hybrid with SQL embedded in it. It has concepts like view (a logical table), dimension (a column or expression you slice by), measure (an aggregation), explore (a join graph the user can query), and model (a collection of explores). Looker's web UI compiles LookML on the fly into SQL against the underlying warehouse.

The product took off in the mid-2010s as cloud warehouses like Redshift and BigQuery made fast SQL feasible, and as data teams started craving the engineering rigor LookML offered. By 2019, Looker was a unicorn, and Google acquired it for $2.6 billion. The acquisition was widely interpreted as Google buying a moat around BigQuery.

What LookML Actually Looks Like

A typical LookML view file:

view: orders {
  sql_table_name: public.orders ;;

  dimension: id {
    type: number
    primary_key: yes
    sql: ${TABLE}.id ;;
  }

  dimension: status {
    type: string
    sql: ${TABLE}.status ;;
  }

  dimension_group: created {
    type: time
    timeframes: [date, week, month, quarter, year]
    sql: ${TABLE}.created_at ;;
  }

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.amount - ${TABLE}.refund_amount ;;
    value_format_name: usd
  }

  measure: order_count {
    type: count
  }
}

This simple file says: there is a table called orders, it has these dimensions, here is how to compute revenue, and here is the canonical formatting. Once it is checked in, every Looker dashboard, every Looker user, every embedded chart will use the exact same total_revenue measure. There is no path to a different answer.

Stack a few hundred files like this together, link them with explore and join blocks, and you have an entire company's metric definitions encoded in a single Git repo. This is genuinely powerful.

The Original Sin

The downside is straightforward: LookML only runs inside Looker. The file format is proprietary. The compiler is proprietary. The engine is proprietary. If you have spent five years writing thousands of LookML files and you decide you want to leave Looker — maybe Google has raised prices, maybe your CFO wants to standardize on Power BI, maybe you want to use a more modern semantic layer — you cannot take your LookML with you in any meaningful way. You have to manually rewrite the entire model in another tool's language.

This is the inverse of the dbt model. dbt's metrics: block is open YAML. Cube's models are open YAML. Even AtScale exports MDX. LookML is the one widely-adopted semantic layer that has no open compiler and no portable export. The lock-in is the reason Google paid $2.6B for Looker.

The category-creator irony: LookML invented the modern semantic layer category and then refused to standardize it. Every open-source semantic layer that came after (Cube, MetricFlow, Malloy) was, in part, a reaction against LookML's closed nature. Malloy, notably, is an open-source modeling language Tabb himself created at Google after Looker was acquired — a tacit admission that the next generation of LookML should be open.

The Opinionated Take

LookML is the most powerful semantic layer in production today and the most painful to escape. Every modern semantic layer either copies its design (dimensions, measures, explores, joins as code) or explicitly rejects it (Malloy, dbt MetricFlow). Either way, you cannot understand the semantic layer category without understanding LookML.

For customers already on Looker, LookML is incredible. For customers wondering whether to adopt it in 2026, the answer is more complicated: the lock-in is real, the alternatives are catching up, and Google's investment in Looker has been inconsistent since the acquisition. The Looker brand has been merged, demerged, and rebranded multiple times under Google Cloud, and the product roadmap has slowed compared to its independent peak in 2017-2019.

The honest prediction: LookML will outlive Looker the brand. Even if Google folds the Looker product into BigQuery and renames everything five more times, the install base of LookML files at thousands of enterprises is too large to die. It will become a legacy format that customers are slowly migrating off of — the COBOL of the semantic layer era.