Looker & Data Studio
Two different BI products that spent four years under near-identical names — the biggest naming confusion in Google Cloud's catalog until the 2026 rename-back. Data Studio — Google's free, self-service dashboard tool, renamed to Looker Studio in 2022 and back to Data Studio in 2026 — does drag-and-drop dashboards with direct connections to BigQuery and Google Sheets, shared by link. Looker (the product Google acquired in 2019) is a paid enterprise BI platform with a semantic layer called LookML, governed metrics, embedded analytics, and a full SDK. Same vendor, similar logo, completely different products.
Picking the wrong one is the most common mistake in the chapter — usually deploying Data Studio for governed enterprise reporting and discovering, months later, that metric definitions have drifted across dashboards because there was no semantic layer to centralize them.
Two Different Products with Similar Names
Data Studiofree, self-serviceLookerpaid, governedDifferent products from the same vendor. The choice is governance and consistency (Looker) versus speed and zero cost (Data Studio).
Before any technical decision, internalize that these are separate products:
- Data Studio — free, browser-based, individually-licensed (or anonymous for public dashboards). Direct connections to data sources. No central metric definitions. A paid Data Studio Pro tier adds team and enterprise management. It was renamed Looker Studio in 2022 and back to Data Studio in 2026 — the shared "Looker" name caused exactly the confusion this page warns about.
- Looker — paid, enterprise BI platform. Centralized data model via LookML. Paid, per-user enterprise pricing (contract-based). Embedded analytics API for SaaS products. The product Google acquired in 2019 from the company called Looker.
When a colleague says "we'll put this in Looker," it can still mean either product — four years of shared naming die hard. Ask which one.
Data Studio — Free Self-Service BI
Data Studio is built for individuals and small teams who need a dashboard fast. Connect to BigQuery, Cloud SQL, Google Sheets, or any of 100+ partner data sources. Drag charts onto a canvas. Share the dashboard by link or embed it. Zero infrastructure and free to use; the paid tier, Data Studio Pro, is priced per user per project and adds enterprise features and support.
The right fit for ad-hoc dashboards, executive reports, public dashboards (a startup's investor metrics page), and team-internal visualizations where slight metric drift across dashboards is acceptable. The wrong fit for governed enterprise reporting where every dashboard must use the same definition of "monthly active users".
Looker — Enterprise BI with LookML Semantic Layer
LookML is the heart of Looker. It is a SQL-like modeling language where you define dimensions, measures, joins, and views once, in code, in a repository. Every chart, dashboard, and embedded view in Looker resolves its data through LookML. The benefit: one definition of "revenue" lives in LookML and propagates everywhere. The cost: someone has to maintain LookML, and the discipline of code review for metric changes.
Looker also offers embedded analytics — a SaaS company can embed governed Looker dashboards into its product, with per-tenant data filtering enforced server-side. This is a real-product-feature use case where Data Studio's lightweight model does not apply.
Integration with BigQuery and Other Sources
Both products integrate with BigQuery, Cloud SQL, Spanner, Sheets, and the rest of GCP's data layer. The integration model differs:
- Data Studio connects directly to the source for each dashboard. Queries flow source-to-dashboard with no intermediate layer. Fast to set up; vulnerable to per-dashboard query cost spikes.
- Looker queries through LookML, which compiles to source SQL. The semantic layer lets you swap underlying sources (BigQuery to Snowflake) without rewriting dashboards. Caching policies, persistent derived tables, and incremental refreshes live at the Looker layer.
When to Choose Which
Data Studio — ad-hoc dashboards, executive views, public-facing metrics, team-internal reports. Free. No semantic layer. Use when speed to first chart matters more than governance.
Looker — enterprise BI where every dashboard must reflect the same metric definitions, embedded analytics in a SaaS product, regulated reporting with auditable lineage. Paid. LookML required. Use when governance and consistency matter more than zero cost.
- Saying "Looker" when meaning Data Studio (or vice versa). The two products differ by orders of magnitude in cost and capability — getting the name wrong leads to mis-scoped projects, mis-budgeted features, and mis-routed support tickets.
- Data Studio chosen for governed enterprise reporting. Without a semantic layer, metric definitions drift across dashboards; nobody agrees what "active user" means anymore.
- Looker chosen for ad-hoc team dashboards where Data Studio would deliver the result for free in a fraction of the time. Overengineering, ongoing per-seat cost, LookML to maintain for charts nobody will look at twice.
- Direct queries against an operational database from a dashboard. Even one popular Data Studio dashboard can hammer a production OLTP database. Use BigQuery as the analytics layer; dashboards query BigQuery.
- No data freshness strategy. Dashboards show data that is hours or days stale; users learn not to trust the numbers. Decide explicit freshness SLAs and cache or refresh accordingly.
- Embedding a Data Studio dashboard via iframe into a customer-facing SaaS product where Looker's embedded analytics SDK is the appropriate tool. The iframe approach lacks per-tenant filtering enforcement, theming, and the SDK's auth model.
- Use the names precisely. "Looker" and "Data Studio" are not interchangeable.
- Data Studio as the default for self-service dashboards; Looker for governed enterprise BI and embedded analytics in customer-facing products.
- BigQuery as the analytics layer between operational databases and dashboards. Never let a dashboard hit an OLTP database directly.
- Materialized views (BigQuery) or persistent derived tables (Looker) for dashboards with frequent reuse of expensive computations.
- LookML in git with code review and CI/CD. Treat metric definitions as code, not configuration.
- Explicit freshness SLAs on every dashboard. Cache or refresh on a schedule that matches the SLA.
Knowledge Check
What is the principal difference between Looker and Data Studio?
- Looker is the older legacy product now being retired, and Data Studio is its modern drop-in replacement that offers all of the exact same capabilities going forward
- They are two different products: Data Studio is a free self-service dashboard tool; Looker is a paid enterprise BI platform with the LookML semantic layer
- Looker is the open-source edition, while Data Studio is the managed commercial version of the same product
- Looker is built for streaming dashboards, while Data Studio is built only for batch-refreshed dashboards
What does LookML provide that Data Studio does not?
- A direct connection to BigQuery without any intermediate query infrastructure or extra connector to configure first
- A central semantic layer where metric definitions (dimensions, measures, joins) live in code and propagate to every chart, preventing metric drift across dashboards
- A built-in machine learning workbench for training, evaluating, and serving predictive analytics models directly against your dashboard data, with no external tooling required
- A free pricing tier offering unlimited dashboards as long as you stay under a monthly usage cap
When is Data Studio the right choice over Looker?
- When the dashboards must be embedded inside a customer-facing SaaS product with strict per-tenant data filtering enforced on the server side for every request
- When every dashboard across the company must reflect exactly the same governed metric definitions org-wide
- For ad-hoc dashboards, executive views, public-facing metrics, and team-internal reports where speed to first chart matters more than centralized governance
- For regulated reporting where every single metric change must carry an auditable lineage record
Why route dashboards through BigQuery instead of querying an operational database directly?
- BigQuery is the only data source that Looker and Data Studio are able to connect to for charting
- A popular dashboard can hammer the OLTP database with concurrent expensive queries; BigQuery as an analytics layer isolates that load and is built for the access pattern
- BigQuery automatically caches the result of every single query, which entirely eliminates any need for materialized views or persistent derived tables in a dashboard pipeline
- Operational databases do not expose enough columns for BI use cases, so BigQuery adds the missing derived columns automatically on load
A SaaS company wants to embed governed dashboards into its product with per-tenant data filtering enforced server-side. Which is the right fit?
- Data Studio embedded via a plain iframe — by far the simplest and fastest deployment path the team could possibly ship
- BigQuery direct query results rendered with custom front-end charts the team builds in house
- Looker's embedded analytics SDK — designed for this case, with auth, theming, and per-tenant filtering built in
- Cloud Run hosting a custom React dashboard that calls BigQuery on demand for each tenant
You got correct