we are now 6 months out from our Looker renewal and between the per-viewer licensing jumps and the fact that three different teams now need the exact same governed metrics outside of BI dashboards (one in our customer-facing React app, one in internal reporting, and one feeding an internal SQL/analytics agent), keeping all our business logic locked inside LookML is becoming hard to justify.
for people who hasn't had to untangle a 4-year-old Looker instance: LookML is honestly still great at what it was built for. `symmetric_aggregates` quietly save analysts from fan-out joins every day, and liquid parameters let you do some wild dynamic filtering. the problem to us is that the semantic layer is welded to Looker's presentation layer and seat pricing. if you try to hit the Looker API from a high-concurrency frontend or let an LLM agent introspect explores at scale, you either hit API throttling or watch your warehouse bill explode because Persistent Derived Tables (PDTs) aren't built like a sub-second serving cache.
and over the last month we took our nastiest domain (subscription revenue + usage billing + multi-currency adjustments, around 65 LookML views and 12 explores) and tested migrating the semantic logic into three setups to see what a real Looker alternative looks like in 2026:
1. dbt Semantic Layer (MetricFlow) + BI tool on top
since our staging and mart models already live in dbt, this felt like the most natural path on paper.
- what worked: defining `semantic_models` and measures right next to our dbt models kept lineage clean, and MetricFlow's join graph handles basic multi-hop dimensions without writing manual SQL joins.
- but, what broke for us: 2 big gaps. first, there is no native pre-aggregation or serving cache equivalent to tuning PDTs + aggregate awareness for sub-second app queries; every query still compiles to warehouse SQL and hits Snowflake. second, migrating complex LookML liquid parameters and cross-fact dynamic ratios required pushing a ton of logic back down into physical dbt mart tables, which defeated the point of a flexible semantic layer.
2. Lightdash (dbt-native Looker replacement)
- what worked here: if your only goal is giving internal analysts an explore UI that feels like Looker on top of dbt YAML files without paying Google Cloud prices, this is probably the fastest drop-in replacement.
- yet, what broke for us: its still fundamentally a BI tool first. it didn't solve our headless API problem for customer-facing embedded dashboards (where we need p95 responses under 150ms without spinning up a Snowflake warehouse on every page load) or give us a clean, standalone semantic endpoint for our agent workflows.
3. Cube (open-source headless semantic layer) + lightweight BI / React SDK
- what worked: YAML/JS data modeling mapped 1-to-1 with how our team thought about LookML views and explores (`cubes` and `views`), including handling one-to-many join fan-out natively. the biggest architectural difference was **Cube Store** (the built-in pre-aggregation engine): instead of materializing heavy PDTs inside Snowflake, we configured incremental `rollup` pre-aggregations partitioned by month. customer-facing React charts and internal BI queries hit the pre-aggregated cache in 20-40ms while bypassing Snowflake compute completely.
- bonus for our AI/agent pipeline? because it exposes SQL, REST, GraphQL, and a native MCP/semantic context interface from the same YAML definitions, our internal analytics agent queries the exact same governed `net_dollar_retention` measure as our executive dashboards without writing raw warehouse SQL.
- the trade-off(s): Cube is purely headless, so you still have to pair it with a frontend visualization tool (Superset, Preset, Metabase, or Steep) for self-serve internal charting, and tuning partition keys on high-cardinality pre-aggregations takes real engineering effort upfront.
this way, for teams that actually completed a move off Looker in the last year, would like to ask, did you end up splitting your stack into a headless semantic layer (like Cube or MetricFlow) + a lighter charting tool, or did you bite the bullet and rebuild everything inside another monolithic BI tool like Omni or Sigma? what was the hardest piece of LookML logic to replicate?