Looker Two Years After Google: What Changed for Consultants

When I wrote the first version of this overview at the end of 2019, Looker had just been bought by Google for $2.6 billion and the product was still recognizably the same thing it had been the year before: a single platform built on LookML, sold mostly through JumpStart engagements, with one BI tool to talk about. Two years later, the picture is messier and more interesting. Google split the brand. The pricing model rotated. The competitive set looks nothing like 2019. And the question I get from clients is no longer “should we evaluate Looker?” but “which Looker do you mean?”

This is a refresh of the original review with everything I have learned from shipping six Looker implementations across the post-acquisition years. The structure is the same. The verdicts are not.

What Google actually did to Looker

In April 2022 Google rebranded the old Data Studio as Looker Studio. They kept the original Looker as a separate product, and they shoved the two of them under the same marketing umbrella. To a buyer who has not lived inside the stack, this looks like a single platform with two surfaces. It is not. They share a name and a logo, and almost nothing else.

Looker (the LookML one) is still the modeled-semantic-layer tool. You build LookML to describe your tables, joins, and metrics, and analysts and business users explore from that model. Pricing is per platform plus per-seat, contract is annual, and the cheapest realistic deployment lives in the mid five figures per year.

Looker Studio (the renamed Data Studio) is a free dashboarding tool that connects directly to data sources. There is no semantic layer worth the name. It is a competitor to Google Sheets charts and to the free tier of Power BI, not to the original Looker. The paid version, Looker Studio Pro, adds team workspaces and a Pub/Sub integration. It does not turn Studio into a real BI platform.

If a client says “we are on Looker,” ask which one. The two products solve different problems for different teams, and a recommendation that fits one is usually wrong for the other.

Database support, then and now

The 2019 list of supported warehouses was already long: Postgres, MySQL, BigQuery, Snowflake, and the usual suspects. In 2026 the list has grown to cover effectively every serious cloud warehouse, including Databricks SQL, Trino, and the lakehouse engines that were not on anyone’s radar three years ago.

Two things have not changed.

First, there is still no ClickHouse adapter, and given Google’s ownership I would no longer wait for one. If your stack is built on ClickHouse, look at Superset, Metabase, or the warehouse-native query layer instead.

Second, you still cannot build a single model that joins across databases. Every analytical question has to be answered from one warehouse, which is fine for most clients because the modern stack pushes everything into one warehouse anyway. It is a hard wall the day a client wants to mix a transactional Postgres with a Snowflake mart for a single Explore.

LookML in 2026

LookML is the load-bearing part of the original Looker, and it is also the part that most teams underestimate. The syntax reads like CSS, but writing it well is a modeling job, not a markup job. You are deciding what a metric means, what the grain of a table is, what counts as a dimension, and how aggregations roll up. Whoever owns LookML owns the definitions every dashboard and Explore in the company will use.

What changed since 2019: more teams now have dbt sitting in front of Looker. The clean split is dbt builds the marts, LookML describes how analysts can explore them. When the split is muddy and LookML re-derives logic that dbt already computed, you end up with two definitions of revenue and one of them is wrong. The cleanup work I do most often on Looker engagements in 2026 is not adding new dashboards. It is auditing where the metric logic actually lives and moving it back into dbt where it belongs.

Explore is still the killer feature, with one caveat

Explore lets a business user pick a date range, choose dimensions, drop in metrics, and produce a chart without writing SQL or talking to an analyst. In 2019 I called this the killer feature, and I still do. Nothing in the Looker Studio side of the brand comes close, and most of the open-source competitors have something rougher in the same shape.

The caveat is that Explore depends entirely on LookML quality. If the model is well structured, business users find what they need and analysts get their afternoons back. If the model is a mess, Explore surfaces broken joins and wrong totals faster than any other BI tool I have used. It is a magnifier, not a fix.

The practical implication: do not buy Looker hoping it will untangle a messy warehouse. Buy Looker after the warehouse is in shape. Otherwise you have spent six figures to put a beautiful interface on top of bad data, and the only thing it accelerates is your stakeholders losing trust.

Looks and dashboards

Saved reports (Looks) and dashboards are still here and still useful. The model is the same as before: filter and visualize an Explore, save it as a Look, group Looks into a dashboard, apply global filters across the whole dashboard. Drill-through still passes context from one report to another, which is one of the small touches that keeps Looker ahead of cheaper tools for actual analytical workflows.

The under-rated feature in 2026 is scheduled delivery to Slack and email with embedded PNGs. Most stakeholders never open the BI tool. They read summaries in their inbox or in their Slack DMs. Looker’s delivery system makes that workflow boring, which is the highest compliment you can pay to plumbing.

Symmetric aggregates

This was a curiosity in the 2019 article and it is still worth the half page. When you join tables in a denormalized model and try to count distinct values, the naive SQL double-counts because the join fans out the rows. Looker handles this transparently by generating SQL with hashed deduplication inside the aggregate. The generated query is ugly and clever, and most users never see it. If you are coming from a hand-rolled SQL world, the first time you read the generated SQL is a small epiphany.

Pricing, then and now

The original article noted that an Explore seat was billed separately and that JumpStart was a minimum $6,000 commitment. Both are obsolete.

The current model is platform-plus-users, with the platform fee in the five-figure range per year and per-user pricing tiered by what the user can do. The cheapest real deployment I have priced in 2026 lands around $30,000 to $50,000 per year before implementation. Implementation through Google or a partner runs another $40,000 to $100,000 depending on how much LookML scope is included.

Looker Studio is free. Looker Studio Pro is roughly $9 per user per month. The two products live in price-point worlds that are an order of magnitude apart, which is the clearest way to see that they are not really one thing.

For a client comparing Looker against Metabase Cloud, Tableau Cloud, or Power BI Pro, the cost conversation now looks like this: Power BI Pro is the price floor, Metabase is the small-team default, Tableau is the legacy enterprise default, Looker is the high-end semantic-layer choice you justify with the value of a single shared definitions layer. If you cannot articulate that value, you are buying the wrong tool.

Where Looker still wins, and where it does not

The places where I still recommend Looker in 2026:

• A team that has invested in dbt and wants a serious semantic layer for analysts and stakeholders to explore from
• An organization where multiple teams need to share definitions and where governance of those definitions matters more than the cheapest possible license
• A stack already deep on BigQuery, where the integration is tightest

The places where I no longer recommend it:

• Small teams who want a dashboarding tool and will not invest in modeling. Pick Metabase.
• Teams that need to mix data from databases that do not live in the same warehouse. Pick Redash or build a thin warehouse layer first.
• Teams on a ClickHouse-first stack. Pick Superset.
• Any team whose first question is “how cheap can we get this.” The honest answer is they are not the target buyer, and pretending they are wastes everyone’s time.

The competitive landscape, redrawn

In the original review the comparison set was Redash, Superset, and the legacy Tableau install everyone had inherited. In 2026 the map looks different.

Power BI grew into the default for any organization already on Microsoft. The integration with Fabric and the Office stack is the moat, and most clients I see in that bucket never seriously evaluate anything else. Tableau is still the senior-analyst default in enterprises with a long Tableau history, kept alive by the muscle memory of the people who actually use it, but I see fewer greenfield Tableau decisions every year. Metabase took the small-team and product-analytics market that used to belong to Redash, and they did it by making the open-source version genuinely usable and the cloud version cheap enough to skip a procurement cycle. Superset is the choice for teams who want open source with a real model layer and have an engineer who is willing to own it.

Looker sits above all of these on the price axis and on the modeling axis. It is the choice you make when the cost of one wrong number is high enough to justify a semantic layer that everyone shares. Most of my engagements end up at Looker for exactly that reason. Most of them could have ended somewhere else if the team had not been ready to invest in modeling first.

A note for consultants

The single biggest shift in the post-acquisition years is that Looker no longer sells itself by demo. The product is too dense and the buying conversation is too long. What sells is a clean migration plan from whatever they have today, a credible LookML model that matches their warehouse, and a 30 to 60 day path from purchase to first dashboard that a real stakeholder uses. Anyone who is willing to do that work has more business than they can handle. Anyone who is selling Looker on features is selling against the wrong list.

The 2019 review ended with a list of related reading on Redash and Superset. In 2026 the comparison set is different. The work, mostly, is not.