Looker is Google Cloud's BI platform built around LookML, a version-controlled modeling layer that defines dimensions, measures, and joins once and reuses them across every report. Instead of letting each analyst write ad-hoc SQL against the warehouse, Looker compiles dashboard interactions into SQL at query time and runs it directly against BigQuery, Snowflake, Redshift, or another database. For data engineers, that makes the semantic model a code artifact you review, test, and deploy like the rest of the pipeline.

LookML: the modeling layer

A LookML model maps physical tables to view files (dimensions and measures) and wires them together in explore files (join graphs). Metrics like revenue or active users are defined once as measures, so two dashboards can't disagree on the definition. Files live in a Git repository, and Looker has built-in branching, pull-request validation, and a SQL runner for debugging the generated queries.

view: orders {
  sql_table_name: analytics.orders ;;

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

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

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.amount_usd ;;
    value_format_name: usd
  }
}

Query pushdown and warehouse load

Looker does not cache a copy of your data by default; every Look and dashboard tile becomes a SQL query against the source warehouse. This keeps results fresh but means dashboard cost lands on your warehouse bill. Engineers manage this with persistent derived tables (PDTs), which materialize expensive subqueries on a schedule into the warehouse, and with datagroup-based caching that ties result freshness to ETL completion rather than a fixed timer. Aggregate awareness lets Looker rewrite a query to hit a small rollup table when the requested grain allows it.

Governed metrics for downstream tools

Because metrics live in LookML, Looker can serve them beyond its own dashboards. The Looker API and the embedded SDK let applications request a measure by name, and the semantic layer can feed governed definitions to spreadsheets or notebooks so the numbers match what executives see. This is the main reason teams pick Looker over a self-serve tool: one definition of "monthly recurring revenue" rather than dozens of copy-pasted SQL snippets. Compare the lighter-weight self-serve approach in Metabase and the analyst SQL-and-notebook workflow in Mode.

Frequently asked questions

Is LookML required, or can I just write SQL? You can run raw SQL through the SQL Runner and build a Look from it, but the governed model, joins, and reuse all depend on LookML. The platform is designed around the modeling layer.

Does Looker store my data? Not by default. It generates SQL against your warehouse on each query. PDTs and the aggregate tables it builds are the exceptions, and those are written back into your own database.

What's the difference between Looker and Looker Studio? Looker (formerly Looker Enterprise) is the LookML-governed platform. Looker Studio (formerly Data Studio) is a free, lighter dashboarding tool with no semantic modeling layer.

How do I control warehouse cost from Looker dashboards? Use datagroup caching keyed to your ETL, persistent derived tables for heavy joins, aggregate awareness for rollups, and query limits per role. Watch the warehouse query logs to find dashboards generating expensive scans.