Executive summary
Looker (now part of Google Cloud) is a mature BI platform whose central innovation, LookML, gave the analytics world a real semantic layer years before "semantic layer" became fashionable again. LookML lets data teams declare views, explores, measures, dimensions, and access controls in a versioned modelling language. Looker resolves user clicks into SQL and renders results as dashboards, looks, and visualisations. For human-facing analytics, this stack works well.
Colrows is built for what comes after BI. It is a semantic execution layer designed to operate the AI-agent layer of the enterprise - autonomously building a typed semantic graph across the data estate, then compiling every agent intent into governed, deterministic, dialect-perfect SQL. Where LookML is hand-authored and resolved at presentation time, the Colrows graph is built and maintained autonomously and resolved at compile time.
In short:
- Looker helps people see data through dashboards.
- Colrows enables systems to compile intent into governed SQL.
For organisations whose roadmap runs from BI to AI agents, the architectures diverge - and the difference is foundational, not incremental.
Two philosophies, two outcomes
Looker assumes meaning is declared once and consumed by humans. Analytics engineers write LookML; users explore through Looker's UI; the platform composes SQL on demand. The semantic layer is rich within LookML's vocabulary - measures, dimensions, joins, derived tables, access filters - but it is bound to Looker's runtime and its assumption that the consumer is a person clicking through curated explores.
Colrows assumes meaning is distributed across systems and consumed by machines. Definitions live in catalogues, dbt models, BI tools (including Looker), runbooks, Confluence, and historical query usage. Colrows ingests these sources and constructs a typed semantic graph autonomously. The graph is multi-scope (global, datastore, persona, user) and uses multi-vector embeddings (definition, usage, combined per concept). The consumer is an agent that generates intent in natural language and needs that intent compiled deterministically.
The downstream consequence: Looker scales with the LookML modelling effort your team can sustain. Colrows scales with the data, documentation, and usage signals you already have.
BI semantic layer vs. semantic execution layer
The most important architectural distinction is what the layer is built to serve.
Looker is presentation-time semantics. A user picks dimensions, applies filters, and clicks Run. LookML resolves the click into SQL inside Looker's runtime. The semantic layer is an authoring artifact that lives in version control and gets compiled when humans request it.
Colrows is compile-time semantics. An AI agent generates intent. The intent is resolved against a typed semantic graph; join paths are proven; RBAC, ABAC, and row/column-level predicates are injected into the SQL before any byte is fetched from the warehouse. The semantic layer is an execution artifact that lives at the centre of every agent query, with a point-in-time reproducible audit trail.
Both are real semantic layers. They are not interchangeable.
A concrete scenario: regulated portfolio review
A financial services firm runs Looker for its analyst-facing dashboards. The LookML project is well-maintained, access filters segment customer data by region, and the analytics team is rightly proud of its work. Analysts run their portfolio reviews from saved Looker dashboards every Monday morning.
Now the firm wants to build an autonomous portfolio review agent: "Investigate why our distressed-asset recovery rate dropped in Q3, and propose corrective actions while staying inside RBI SARFAESI and DRT regulatory scope." The agent must reason across:
- Loan, Borrower, RecoveryEvent, Collateral, and RegulatoryScope entities and the relationships between them.
- The compliance officer persona's access to specific borrower-PII columns, but only when scoped to active enforcement files.
- Predicates that vary per regulatory framework, which change as new RBI circulars are issued.
- An audit trail proving which definitions and policies were in force when the agent reached its conclusion.
Looker can render the historical recovery-rate chart. LookML access filters can hide rows for some users. But the agent reasoning is multi-hop, the governance is multi-scope, the policies evolve mid-quarter, and the audit must be defensible to a regulator. None of this is a Looker problem, because Looker was not designed to be the runtime for autonomous agents.
With Colrows, the agent compiles its intent through a typed semantic graph that already encodes the entities, relationships, and regulatory scopes. Compile-time governance injects the right predicates per persona, per file, per date. The audit trail is point-in-time reproducible. New circulars ingested as documentation update the graph without a LookML deploy.
Why BI semantic layers cannot do this
Looker is excellent at one thing: helping humans explore curated data through visualisations. It is not designed to:
- Compile free-text agent intent into governed SQL deterministically.
- Inject row/column-level predicates at compile time across persona, tenant, and regulatory scope.
- Build or maintain itself from documentation, runbooks, and usage signals.
- Produce machine-readable compile traces for AI audit.
- Resolve the same concept differently across multi-scope semantics without forking the LookML view.
Each of those is foundational for putting AI agents into production. Adding them on top of Looker is not a configuration change - it is a different architecture.
What evaluators actually compare
Pricing
Google does not publish Looker list prices: the official pricing page (June 2026) shows "Call sales" for all three editions - Standard, Enterprise, and Embed - on annual commitment, each including one production instance, 10 Standard Users, and 2 Developer Users. What the page does publish is the meter on Looker's AI: monthly Gemini Data Token allocations per edition (60M input / 1.2M output on Standard, up to 1.2B / 24M on Embed), with overage pricing of $3.00 per 1M input tokens and $20.00 per 1M output tokens effective 1 October 2026 - a line worth modeling if conversational usage succeeds. For actual spend, third-party analyses report Standard-edition platform fees around $60,000-66,600/year plus per-user adders, and marketplace data attributed to Vendr puts the average Looker contract near $150,000/year across 355 analyzed deals - reported figures, not list prices, cited here as such.
Colrows has a free tier - unlimited datasources, users, and access policies with metered compute - and custom Enterprise pricing for SSO/SCIM, dedicated infrastructure, and SOC 2 / HIPAA-aligned deployments.
Modeling effort: the LookML practice
Looker's governance strength and its operational cost are the same fact: everything flows through hand-authored LookML. The public record is consistent on what that costs. G2 reviewers describe a "steep learning curve, especially when working with LookML"; a Gartner Peer Insights reviewer notes that while LookML is powerful, "the learning curve can be a bit steep for non-devs, and this sometimes means data requests still bottleneck with the engineering team." The structural critique - that teams end up modeling data twice, once in the warehouse and again in LookML - comes from a competitor (Sigma), so weigh it accordingly, but it matches the bottleneck reviewers describe. At scale there are operational edges too: consultancy write-ups report the LookML validator slowing significantly as codebases grow.
Colrows removes the authored-artifact bottleneck rather than optimizing it: the semantic graph is built autonomously from the estate and maintained with drift detection, and multi-scope resolution (global → datastore → persona → user) handles the per-domain meaning that LookML handles by forking views.
Looker's AI, for fairness
Looker is not standing still: Gemini-powered Conversational Analytics went GA in 2025 and extends to all Looker platform users. It is grounded in - and bounded by - the LookML you author, and metered by the data tokens above. The evaluation question this page exists to sharpen: if the semantic context must be excellent for the AI to be trustworthy, who builds and maintains that context, and what enforces it at compile time?
Migration and coexistence
LookML projects seed the Colrows semantic graph - views, explores, measures, dimensions, access grants - and most estates keep Looker for analyst dashboards while Colrows takes the agent-execution and governed conversational surface. Existing LookML investment carries forward instead of being rewritten.
Pricing visibility, token metering, and review quotes reflect the cited pages as of June 2026; contract figures are marketplace data reported by third parties, attributed as such.
Reframing the comparison
Looker and Colrows operate at different layers of the modern data stack.
Looker = presentation-time BI semantic layer. Optimised for human-facing dashboards and curated exploration. LookML is hand-authored. Resolution happens inside Looker's runtime.
Colrows = compile-time semantic execution layer. Optimised for governed, deterministic compilation of AI agent intent. The semantic graph is built and maintained autonomously. Resolution happens before any SQL touches the warehouse, with policy injected at the SQL level.
The two coexist cleanly: keep Looker for analyst dashboards; add Colrows for the agent-execution surface that compiles intent into governed SQL.
The bottom line
If your goal is mature human-facing BI - dashboards, embedded analytics for customers, and a hand-authored modelling language your analytics team owns - Looker is a capable choice and a sensible default for many enterprises.
If your goal is to put AI agents into production - to compile their intent into governed SQL with proven joins, compile-time policy enforcement, and a semantic graph that evolves autonomously with your business - Looker alone is not the right architecture. The semantic execution layer above it is what matters, and that is what Colrows provides.
At the core
| Looker | Colrows | |
|---|---|---|
| Built for | BI dashboards and exploration | Semantic execution for AI agents |
| Primary consumer | Humans clicking dashboards | AI agents, autonomous workflows |
| Core strength | Visual exploration and embedded BI | Governed compilation of agent intent |
| Intelligence lives in | LookML files and Looker UI | Typed semantic graph |
Semantic and intelligence handling
| Capability | Looker | Colrows |
|---|---|---|
| Semantic model | Manual LookML | Autonomous, continuously maintained |
| Resolution time | Presentation time (human click) | Compile time (agent intent) |
| Multi-scope resolution | Per-user via access filters | Global, datastore, persona, user scopes |
| Context preservation | Per-session | Cross-workflow, persistent |
| AI readiness | Indirect via Looker API | Agent-native by design |
| Explainability | SQL-runner inspection | End-to-end (intent → semantics → SQL → source data) |
Engineering and operational reality
| Dimension | Looker | Colrows |
|---|---|---|
| Compile-time governance | Partial - access filters and grants | Yes - RBAC/ABAC injected into generated SQL |
| Join path proof | Schema-checked via explores | Proven against typed graph at compile time |
| Drift handling | Manual LookML updates | Autonomous detection plus proposed mappings |
| Cloud lock-in | Tied to Google Cloud | Warehouse and cloud agnostic |
| Audit trail | System Activity logs | Point-in-time reproducible compilation trace |
| Coexistence | - | Ingests LookML; Looker continues for dashboards |
Frequently asked questions
Is Colrows a Looker replacement?
For dashboarding and visual exploration, no - Looker is a BI tool and Colrows is not. For the semantic layer underneath your AI agents, yes - Colrows replaces LookML as the source of truth for compiled, governed query intent. Many enterprises run Colrows as the agent-execution layer while keeping Looker for human-facing dashboards.
Can Colrows ingest LookML definitions?
Yes. Views, explores, measures, dimensions, and access grants from a LookML project can seed the Colrows semantic graph. From there the graph evolves autonomously, ingests other documentation sources, and exposes the agent-native compile pipeline that Looker does not provide.
Why is a BI semantic layer not enough for AI agents?
BI semantic layers like LookML resolve meaning at presentation time, primarily for humans clicking dropdowns and writing filters. AI agents generate intent in free text. The layer between them and the warehouse must compile that intent deterministically, with proven joins and compile-time governance - not just look up a metric definition. Those are different architectural problems.
Does Colrows support visualisation?
Colrows includes self-serve dashboards built on its semantic graph, but visualisation is not the product's centre of gravity. The centre of gravity is compiling agent intent into governed SQL. For full BI-tool feature breadth, Looker remains a stronger fit. For trustworthy AI execution, Colrows is built for it.
How does Colrows compile-time governance compare to LookML access controls?
LookML supports access_filter, access_grant, and PDT permissions that the BI layer enforces against authenticated user sessions. Colrows enforces RBAC, ABAC, and row/column-level predicates at compile time, before any SQL is generated. Filtered-out rows are never read; unauthorised intent fails compilation rather than reaching the warehouse. This matters more for AI agents than for humans because agent volume and unpredictability stress the governance layer differently.
Is Colrows tied to Google Cloud the way Looker is?
No. Colrows is warehouse-agnostic and runs across Snowflake, Databricks, BigQuery, Redshift, Postgres, MySQL, ClickHouse, Trino, and 8+ more. Deployment options include Cloud, dedicated, and fully private VPC across AWS, Azure, and GCP.
How much does Looker cost?
Google publishes no list prices - all three editions are "Call sales," annual commitment, each including one production instance, 10 Standard Users, and 2 Developer Users. Third-party analyses report Standard platform fees around $60-66K/year plus per-user licenses, and marketplace data attributed to Vendr puts average contracts near $150K/year. Budget also for Gemini Data Token overage from October 2026 ($3/1M input, $20/1M output) if conversational usage scales.
How steep is the LookML learning curve?
Steep enough to be the recurring theme in public reviews: G2 reviewers cite it directly, and Gartner Peer Insights reviewers report data requests bottlenecking with the engineering team because business users cannot self-serve in LookML. Treat LookML as a software practice - with developers, code review, and a backlog - when sizing total cost.
Does Looker have conversational AI?
Yes - Gemini-powered Conversational Analytics went GA in 2025 for Looker platform users, grounded in your LookML model and metered in data tokens. The architectural difference from Colrows is the grounding artifact (hand-authored LookML vs an autonomous semantic graph) and the enforcement point (Looker's runtime vs compile-time governance in the generated SQL).
Further reading
- Deterministic vs Probabilistic Text-to-SQL: A Buyer's Framework - the accuracy evidence and the seven evaluation questions.
- Semantic layer platforms compared - the capability matrix across the category.
- What is a semantic layer? (Pillar guide) - the definitive 2,000-word guide to the category.
- Colrows vs Cube.js, vs dbt Semantic Layer, vs AtScale, vs ThoughtSpot - other competitor comparisons.
- Semantics for Enterprise AI Agents - why generic LLMs fail at enterprise tasks and what an explicit semantic layer changes.