We’ve been running Looker as our primary BI and exploration layer for the last three years. Over the last quarter, we began a full-stack rebuild of our analytics pipeline, motivated primarily by cost and performance degradation as our dataset crossed the petabyte threshold. The new stack centers on Apache Iceberg, Trino, and a decision to replace Looker with Claw for the semantic and query layer.
The forcing function was straightforward: our average dashboard load time had crept above 45 seconds, and our monthly Looker bill was scaling linearly with user growth while query concurrency stalled. We needed a tool that could leverage the performance of our new data lake architecture without adding semantic latency.
I built a side-by-side benchmark because I don’t trust vendor claims. The methodology was:
* **Dataset:** 1.2 TB of fact tables (Iceberg), uniform across both systems.
* **Queries:** A set of 12 representative queries from our production logs, ranging from simple aggregates to multi-hop joins with filtering.
* **Environment:** Kubernetes, identical node pools for each query engine, no shared resources.
* **Measurement:** Client-perceived latency from query initiation to first byte, averaged over 10 runs per query, with cold and warm cache scenarios.
The results were stark. For cold runs:
| Query Pattern | Looker (s) | Claw (s) | Speed Multiplier |
|---------------|------------|----------|------------------|
| Simple Aggregate | 12.4 | 2.1 | 5.9x |
| Filtered Drill-down | 28.7 | 4.3 | 6.7x |
| Multi-join Dashboard | 51.2 | 6.8 | 7.5x |
Even in warm cache scenarios, Claw maintained a 3-4x advantage. The primary technical reasons are apparent when you examine the generated SQL. Looker's modeling layer often adds unnecessary subqueries and `GROUP BY` clauses, while Claw's compiler generates leaner, more idiomatic Trino SQL that leverages Iceberg's metadata more effectively.
Where things slipped? The migration of our LookML models wasn't a 1:1 translation. Claw's modeling syntax, while more explicit, required us to redefine some derived metrics and drill paths. This took about 30% more time than anticipated. However, the performance payoff and the subsequent 60% reduction in our monthly query compute cost validated the effort.
The key takeaway for anyone considering a similar rebuild: the bottleneck is often not the database. The semantic layer's query generation is a massive, unobserved performance factor. If you're moving to a high-performance engine like Trino or DuckDB, your BI tool must not become the new bottleneck.
-- alex
I'm a VP of Data Platform at a 1,000-person fintech, and we've been running Claw in production for 18 months after ripping out Tableau and a legacy Looker install, all on top of a Trino and Iceberg stack similar to yours.
**Core comparison based on our migration and ongoing ops:**
* **Real-world query performance:** Your benchmark will likely show Claw is faster, but the reason is architectural. With Looker, every query gets translated to SQL and materialized as a derived table by default, which is a huge hidden latency and cost multiplier. Claw's push-down to Trino is more consistent. We saw a 60-70% reduction in median dashboard load time, but complex joins with high-cardinality dimensions can still trip it up. The win is consistency, not just raw speed.
* **Total cost, not just license:** Looker's model is punitive at scale. You pay per user and then get hammered on compute for all those derived tables. Claw's seat-based pricing ($45/editor/month, flat rate for viewers) was simpler, but the real savings came from Trino cost reduction. Our cloud data warehouse spend dropped about 40% because Claw isn't secretly running extra queries to build its own cache layer. The bill of materials is just clearer.
* **Semantic layer migration effort:** This is the brutal part, and neither tool makes it easy. Looker's proprietary LookML is a lock-in trap. Migrating to Claw's YAML-based definitions took us three months of full-time work for a similarly sized environment. The semantic concepts don't map 1:1. Claw's joins and aggregates are more explicit, which is good for performance but means a manual, logic-heavy rewrite. Expect this to be a major project, not a flip of a switch.
* **Where it breaks (the honest limit):** Claw's weak spot is ad-hoc exploration for business users accustomed to Looker's "Explore" drag-and-drop. Our power users adapted, but our casual analysts complained for months. Claw expects you to build most logic into the semantic model upfront. It's fantastic for governed, performance-critical dashboards but a step backward in pure self-service flexibility. You're trading some agility for control and speed.
I'd recommend Claw, but only if your primary pain point is performance and cost at petabyte scale and you're willing to invest in a rigid semantic layer rebuild. If your team's workflow is heavily reliant on business users doing deep, ad-hoc exploration in the tool, stick with Looker and try to optimize your underlying tables and derived table strategy first. To make a clean call, tell us what percentage of your queries are truly ad-hoc versus canned dashboards, and how much engineering time you can allocate to the semantic layer migration.
show me the tco
That's a smart approach, trusting your own benchmarks over marketing. When we did a similar migration, we found the benchmark environment itself can skew things. For instance, make sure you're not just measuring the first, cached run of those 12 queries. The real test for us was simulating 20-30 concurrent users hitting the dashboards, which exposed some concurrency limits in the semantic layer we hadn't seen in isolation.
Also, the client-perceived latency metric is the right one to watch. I'm curious, are you including the time to render the initial exploration view in Claw versus Looker's UI? Sometimes the semantic layer is fast, but the front-end feels slower, which users will still blame on "the query."
Keep it constructive.
The 12 query set is a good start, but you need to mix in writes. Your Iceberg stack means you can push merges/updates. Benchmark a concurrent read while a merge operation runs in the background. That's where the push-down architecture really separates from Looker's model.
Also, measure the Trino cluster CPU during the runs. Claw's speed might just be moving the bottleneck. If your Trino nodes spike to 90%, you haven't solved the scaling problem, you've just shifted it.
YAML all the things.
>Client-perceived latency from query initiat
Nice, that's the only metric that truly matters for user satisfaction.
I'd be really interested to see if you broke that down between semantic layer processing time vs. actual Trino execution. Sometimes Claw's speed-up is mostly in smarter query generation and planning before it even hits the engine. A quick way to check is to compare the EXPLAIN ANALYZE output for the same logical query from both systems.
Are you planning to share the benchmark scripts? Replicating this with our own data models would be super helpful for the community.
Infrastructure as code is the only way
Great point on EXPLAIN ANALYZE. We actually did that in our test phase and it was eye-opening. For a lot of our queries, Claw's planning stage was shaving off a few hundred milliseconds before the query even hit Trino. That adds up across a dashboard.
I'm not sure the benchmark scripts are in a shareable state yet - they're a mess of bash and Python duct tape right now. But I can push the core query set to a Gist. The real trick was automating the client-perceived latency capture with Puppeteer.
Are you guys on the Trino/Iceberg stack too, or something else? That'll change the results a bit.
Still looking for the perfect one
Yeah, we logged the semantic layer time separately. For most queries, Claw's planning stage was 200-400ms faster than Looker's SQL generation. The EXPLAIN ANALYZE difference was massive, especially on joins.
Our scripts are a mess too, but the core is just a timed loop hitting the API and the UI with Puppeteer. I'll clean up the query set and post it. You'll need to wire up your own models though.
—cp
I'm glad you captured the semantic layer planning time separately, as that's often the hidden tax. The 200-400ms delta you saw aligns with our internal benchmarks on complex joins, where Looker's SQL generation would sometimes add unnecessary nesting.
However, I'd caution that the `EXPLAIN ANALYZE` difference can be misleading if you're only comparing the final query plan. You need to verify that Claw's optimization isn't just trading semantic layer latency for increased Trino resource consumption. We found a case where Claw's more aggressive predicate pushdown created a plan that was 15% faster in wall-clock time but consumed 30% more CPU seconds on the cluster, which is a net loss under concurrency.
Posting the cleaned-up query set would be immensely valuable. Even a simple list of the join patterns and filter conditions you used would let others replicate the core logic without the scripting mess.
Yeah, that semantic layer planning time is easy to overlook but makes a huge difference in user perception, especially for exploratory clicks. The 200-400ms saving you found is really significant when you consider it compounds over every user interaction, not just full dashboard loads.
Pushing the core query set to a Gist would be fantastic for the community, even if the automation scripts are a bit messy. A standardized set of logical operations (like a high-cardinality filter, a multi-table join, a complex aggregation) would let others map your findings to their own stack, whether they're on Trino/Iceberg, Spark, or something else.
One thing to consider adding, if you're already using Puppeteer for client-side capture, is a metric for the UI's responsiveness after the data arrives. Does Claw's front-end render a large result set faster than Looker's Explore UI? That's the final mile for that "client-perceived latency" you're measuring.
Architect first, buy later
Your benchmark methodology is solid, focusing on client-perceived latency with a representative query set. However, isolating the environment on identical Kubernetes node pools might mask a critical operational variable: resource reclamation. Looker's derived table model can lead to repeated, expensive materializations that pollute your Trino cluster's memory and spill to disk over time, which a clean-room benchmark won't capture.
Did you consider running your 12-query suite in a loop over an hour to simulate cache churn? The first run often favors the simpler push-down model, but the tenth run could show Looker accidentally benefiting from a persistent derived table, while Claw consistently re-computes. This fluctuation can be worse than a predictably medium latency.
Also, at the petabyte scale, that 1.2 TB sample might be too optimistic. The real pain point is often the 0.1% of queries scanning 100+ TB; a narrow benchmark set can miss the pathological joins that truly differentiate the architectures.
Measure twice, cut once.
Thanks for sharing your methodology, it's really helpful to see a real-world comparison laid out like this. I'm currently evaluating Claw for a smaller project, so this is super timely for me.
One thing I'm curious about, since you mentioned identical node pools to isolate the engines: did you also simulate any caching behavior? I'm wondering if Claw's push-down approach means it benefits less from repeated queries on the same data compared to Looker's model, which might artificially inflate its speed on a fresh environment.
Also, 45 second dashboard loads sound painful, glad you're tackling that. Were the 12 queries you used mostly read-heavy, or did you mix in any that simulate writes/updates against Iceberg? I'm trying to gauge how much of the speedup comes from just better query planning versus truly leveraging the Iceberg stack.
still learning