What Is Looker? Product, LookML, Architecture, and Embedding

Looker is a business intelligence platform for governed data modeling, exploration, dashboards, delivery, APIs, and embedded analytics. Its defining product boundary is not a particular chart. It is the path from a LookML semantic model and user request to generated SQL, database execution, and a delivered result.

That path explains both Looker's value and the work required to operate it.

Looker Turns a Governed Model and a User's Context Into Generated SQL

Google's LookML introduction describes the core flow:

1. A LookML project defines model and view files, joins, dimensions, measures, calculations, and business rules.
2. A user or application selects fields and filters through an Explore, saved content, API, or embedded route.
3. Looker's SQL generator compiles the request into SQL for the connected database dialect.
4. The database executes the query.
5. Looker formats and delivers the result through an Explore, Look, dashboard, schedule, API, or embed.

This is often called an in-database architecture because source tables remain in the connected database rather than being copied into a separate analytical extract as the default query model.

LookML Is the Semantic Contract

LookML is Looker's language for semantic data models. It is dependency-based rather than an imperative application language. A project commonly includes:

• model files that select connections, Explores, joins, and access behavior;
• view files that define dimensions, measures, calculations, and field metadata;
• reusable business definitions and validation rules;
• persistence configuration for derived or aggregate tables;
• Git-backed development and deployment workflow.

Users can then form queries from governed fields without writing SQL. That does not remove semantic work; it moves definitions, join safety, aggregation behavior, access, freshness, and ownership into the LookML project.

Evaluate a Looker implementation by reproducing hard metrics and queries, not by counting model files or accepting a successful compile as proof of correctness.

Source Data, Cache, and PDTs Are Different Boundaries

“Looker does not store data” is too broad. The source warehouse remains authoritative, but several data states matter:

Source tables remain in the connected database and are queried under the configured connection and database permissions.

Query-result cache can store encrypted customer data in Looker. Google's cache documentation documents cache retention and invalidation behavior. Define datagroups, freshness, scope, invalidation, retention, and incident handling explicitly.

Persistent derived tables (PDTs) are written to a scratch schema in the database. Google's derived-table documentation describes persistence strategies and rebuild behavior. PDTs need database write permissions, separate environment schemas, triggers, dependency handling, monitoring, and recovery.

Exports and scheduled artifacts create additional copies with their own destinations, permissions, retention, and support paths.

Data residency and security review should cover each boundary instead of relying on the source-warehouse architecture alone.

Looker's Content Forms Decide What a Reader May Change, Not Just What They See

Looker provides several content forms:

• Explores for selecting dimensions, measures, filters, and visualizations;
• Looks for saved query and visualization state;
• user-defined and LookML dashboards;
• folders and boards for organization;
• schedules, alerts, and delivery destinations;
• APIs and SDKs for automation and custom applications.

The useful distinction is not whether a feature exists but which content form, permission, artifact, and operating owner the workload uses. A dashboard, scheduled PDF, API result, and embedded Explore can expose different risks even when they share a LookML model.

Embedding Is a Documented Product Route

Looker is not accurately described as internal BI with unsupported embedding added later. Google's embedding guide documents private embedding, signed embedding, and signed embedding with the Embed SDK. Each route uses iframe-based Looker content and supports theming; the routes differ in how the iframe and user authentication are managed.

Signed embedding authenticates the user through the host application and creates or updates an embed user from a one-time URL. The request can carry models, permissions, groups, user attributes, session length, and content parameters. For Looker (Google Cloud core), Google's signed embedding documentation requires the Embed edition.

For a production customer-facing route, test:

• host identity to external user, group, model, permission, and user-attribute mapping;
• direct URLs, altered parameters, filters, drill-through, downloads, schedules, and cached results;
• session creation, expiration, logout, user switching, cookie or cookieless behavior, and allowed domains;
• theme, navigation, responsive layout, keyboard access, loading, empty, stale, error, and recovery states;
• API limits, warehouse workload, logs, support evidence, and rollback.

Use the broader embedded analytics security contract for tenant and artifact denial tests.

Looker Prices the Platform and the User Licence Separately, and Publishes Neither in Full

Google's current Looker pricing page separates platform pricing from user licensing. Looker (Google Cloud core) lists:

• Standard for smaller organizations or teams, with a production instance and defined included users and API allowances;
• Enterprise with enhanced security features and larger API allowances;
• Embed for external analytics and custom applications at scale, with larger API allowances.

The annual commitment price for all three is shown as “Call sales.” User types and permissions are priced separately under the contract, and other usage, including current AI-related meters, can add its own allowance or overage model.

Model the complete route: edition, production and non-production instances, developer/standard/viewer treatment, embed users, APIs, AI usage, database queries and storage, network, support, implementation, term, overages, renewal, and exit.

Looker and Looker Studio Are Separate Products

Google's official comparison describes Looker as the governed BI, modeling, administration, API, and embedding platform. Looker Studio is a separate reporting and visualization product with a no-cost version and a Pro offering.

Do not reduce the difference to “enterprise versus simple marketing reports.” Select from the actual requirements: semantic governance, data access, report ownership, connectors, administration, collaboration, embedding route, support, deployment, and commercial terms.

Looker Fits Teams That Can Operate the Estate LookML Creates

Looker is a candidate when a team values governed LookML models, Explore-based analysis, shared content and delivery, database-generated queries, administration, APIs, or a documented embedded route: and can operate the resulting semantic, database, content, identity, and support estate.

It may be a poor fit when the required workload fails its production tests or when the operating and commercial boundary is unacceptable. Company size, startup stage, or a universal implementation timeline does not decide that outcome.

Use one production-shaped slice:

1. Reconcile a hard metric and query against an accepted source.
2. Test allowed and denied roles, models, fields, rows, URLs, and artifacts.
3. Inspect generated SQL, warehouse plan, cache, PDT, and freshness behavior.
4. Complete the intended dashboard, Explore, schedule, API, or embed task.
5. Exercise concurrency, timeout, stale data, failure, recovery, and operator handoff.
6. Price the exact edition and demand model in writing.

If the route fails a material requirement, compare Looker alternatives. For a bounded two-product test, use Looker vs Metabase. For embedded workloads, apply the same evidence to the embedded analytics alternatives shortlist.

Looker's Production Boundary Runs From LookML to the Support Contract

Looker is a governed query and delivery platform built around LookML. Its production boundary includes semantic definitions, generated SQL, database execution, cache and PDT behavior, content, identity, APIs, embedding, artifacts, operations, and commercial terms.

Choose it, or replace it, only after testing that complete route. A semantic model demo, dashboard screenshot, or category label is not enough evidence.

For a purpose-built customer-facing route, compare the same task against an embedded analytics platform without relaxing the metric, tenant, artifact, workload, or operating acceptance rules.