DEV Community: Harshit Chouhan

Looker Pricing in 2026: What Google Publishes, What You Actually Pay

Harshit Chouhan — Wed, 12 Aug 2026 15:39:38 +0000

The Looker quote you receive is not the Looker bill you pay.

The licence covers the platform. LookML is where the budget quietly goes.

What's on the quote vs what lands

Line item	On the quote?	Notes
Platform / instance fee	Yes	The number people compare
Per-user tiers	Yes	Viewer vs Explorer vs Developer
LookML maintenance	No	An engineer's time, permanently
Warehouse compute	No	Billed by BigQuery/Snowflake, not Google
Re-modelling on schema change	No	Arrives as sprint work
Migration if you ever leave	No	Definitions are in LookML, not portable

The per-user tiers deserve attention: a "viewer" who filters a dashboard can reclassify as an explorer. Adoption success shows up as a licensing surprise.

The real cost driver

LookML was the right instinct — put metric definitions in reviewed code instead of scattering them across dashboards. Consistency improved and stayed improved.

The cost is that coverage equals authoring effort. Every new concept is a pull request. Every schema change is maintenance debt. Every question outside the model is a ticket, and the ticket is the actual user experience.

That is fine when the consumer is a human analyst who can wait two days. It stops working when the consumer is an AI agent asking things nobody pre-modelled, at machine rates.

How to build an honest comparison

Price three things, not one:

Licence and platform fee
The engineer who keeps the model current — the salary line nobody puts in the TCO
The latency between a business question and a trustworthy answer

The third is the one with real money in it. Cipla cut decision latency by over 90% and IT report requests by 80% — neither number appears on any BI invoice.

The full breakdown — current published figures, how the tiers actually reclassify users, and a like-for-like TCO model — is here:

👉 Looker Pricing in 2026: What Google Publishes, What You Actually Pay

Originally published at colrows.com/blogs/looker-pricing

dbt Semantic Layer vs Cube vs AtScale: Choosing an Enterprise Semantic Layer

Harshit Chouhan — Mon, 10 Aug 2026 15:55:42 +0000

Three semantic layers, three architectures, three very different bills.

All three will define what a metric means. None of them proves an AI agent is allowed to run it.

Quick orientation

	dbt Semantic Layer	Cube	AtScale
Core idea	Metrics as version-controlled code	Headless API in front of metrics	OLAP-style aggregate acceleration
Strongest when	You want engineering discipline	Many apps consume the same numbers	Heavy, stable aggregate workloads
Modelling	Hand-authored YAML	Hand-authored data model	Hand-authored cubes
Cost driver	Plan tier + query volume	Pre-aggregation builds + compute	Quote-based licence + compute
Governance	Upstream, in the warehouse	In front of the API	On the cube

Each is competent at what it was built for. If your consumers are dashboards and analysts, any of the three will serve you.

The question none of them answers

An agent doesn't arrive with a metric name. It arrives with an intent in English and has to work out which entities, which grain, which joins, and whether it's entitled to any of it.

That exposes two gaps every one of these shares:

Undefined intent has no answer. Coverage is whatever someone remembered to model. Business questions don't respect that boundary.
Authorisation is checked around the query, not inside it. A filter applied after execution means the data already moved.

What to actually evaluate on

Ignore feature matrices and score these five:

Answer a question nobody modelled, on your schema
Show why one join path was chosen over two others
Same question, two users with different entitlements — show both SQL statements
Ask something ambiguous. Refusal or guess?
Reproduce a number from six months ago with the definitions then in force

Most evaluations stop at 1. Numbers 3 and 5 are the ones that decide whether the thing ships in a regulated business.

The full breakdown — architecture-by-architecture comparison, cost profiles, and the migration implications of each — is here:

👉 dbt Semantic Layer vs Cube vs AtScale: Choosing an Enterprise Semantic Layer

Originally published at colrows.com/blogs/dbt-semantic-layer-vs-cube-vs-atscale

The Text-to-SQL Accuracy Cliff: Why Deterministic Compilers Beat LLM Guessing

Harshit Chouhan — Wed, 05 Aug 2026 14:18:33 +0000

Every text-to-SQL demo is flawless. Every production rollout is a coin flip.

The model didn't get worse between the demo and your warehouse. Your schema crossed a threshold it cannot reason past.

Accuracy doesn't decay. It collapses.

The intuition most teams carry is that accuracy degrades gradually as queries get harder. It doesn't. It holds, holds, holds — then falls off a cliff the moment a question needs a join the model has to guess at.

On our own enterprise benchmark, raw schema access scored 14.5%. The same model, given compiled and governed context, scored 98.2%.

Same model. Same questions. The only variable was the context it ran on.

The three gaps that create the cliff

Gap	What the model sees	What it needs
Naming	`cust_t`, `cust_type`, `customer_seg`	One typed entity with synonyms
Joins	200 tables, 3 plausible paths	A proven path, or a hard failure
Rules	No sign of the fiscal calendar	Grain and filters attached to the metric

Any one of these produces syntactically perfect SQL that returns the wrong number. That is the dangerous failure — a query that errors gets fixed, a query that returns 8% instead of 12% gets pasted into a board deck.

Why "temperature: 0" is not determinism

Setting temperature to zero makes sampling greedy, not correct. Greedy decoding over an ambiguous schema reliably picks the same wrong join every time. You have traded variance for consistent error, which is worse — now it looks trustworthy.

Determinism has to come from architecture, not decoding parameters:

The LLM parses language into a typed intent
The semantic graph — not the model — resolves entities, metrics and grain
The planner proves a join path exists, or compilation fails
Policy predicates are injected before SQL is emitted

Ambiguity produces a refusal instead of a guess. That is the whole difference.

The full breakdown — what the famous benchmark numbers actually measure, what failure looks like in real SQL, what a wrong number costs, and how every serious vendor has converged on the same answer — is here:

👉 The Text-to-SQL Accuracy Cliff: Why Deterministic Compilers Beat LLM Guessing

Originally published at colrows.com/blogs/text-to-sql-accuracy-cliff

RAG vs. Semantic Layer: Why AI Needs Deterministic Governance

Harshit Chouhan — Mon, 03 Aug 2026 18:09:55 +0000

Half the market is arguing about whether RAG or a semantic layer is the right foundation for enterprise AI.

They are not competing. They answer different questions, and most teams need both.

Two shapes of question

Every question an agent receives breaks into one of two forms:

"What did we say about X?" — lives in contracts, policies, tickets, docs. Unstructured. RAG was built for this.
"What is true about X?" — lives in your warehouse and governed metrics. Structured. A semantic layer was built for this.

Treating them as rivals is how teams end up with a system that can quote the pricing policy but cannot tell you this quarter's realised price.

Where each one breaks

	RAG	Semantic layer
Good at	Retrieving relevant prose	Resolving definitions and joins
Fails on	Aggregation, math, current state	Anything not modelled as data
Permissions	Flattened at ingest, rebuilt at query time	Compiled per person, per query
Answer stability	Varies with retrieval ranking	Identical by construction
Audit story	Cites a chunk	Reproduces the exact SQL

The permissions row is the one that ends pilots. A retrieval index that ingested everything has, by construction, assembled your most sensitive object — and reconstructing entitlement at query time is guesswork.

The layer that actually decides

Neither a document chunk nor a metric definition is worth much until something compiles it into a governed query and runs it.

That is the piece most architectures are missing: intent → context resolution → constrained planning → governed execution. RAG can feed the first step. It cannot perform the last three.

Point an agent at raw tables and the best models score in the low teens on real enterprise data. Give the same model compiled, governed context and it clears the high nineties. The retrieval quality was never the bottleneck.

The full breakdown — the precise division of labour, why hybrid architectures win, and how compile-time governance closes the gap RAG cannot — is here:

👉 RAG vs. Semantic Layer: Why AI Needs Deterministic Governance

Originally published at colrows.com/blogs/rag-vs-semantic-layer