Strategy Mosaic vs dbt Semantic Layer, Snowflake and Looker
Strategy Mosaic, the dbt Semantic Layer, Snowflake Semantic Views and Looker all promise one definition of revenue. They put your business logic in very different places.
Talk to an expertStrategy Mosaic vs dbt Semantic Layer is a comparison more data teams are running in 2026, usually with Snowflake Semantic Views and Looker on the same shortlist. All four promise the same thing: define revenue, margin and customer once, and get the same number in every dashboard and every AI agent.
They do not put your business logic in the same place. That is the real decision. Mosaic keeps it in an independent vendor layer, dbt in your transformation project, Snowflake in your warehouse and Looker in your BI tool. Each choice is a form of lock-in. The question is which one you can live with.
I was a Looker solution partner during the Google acquisition and have migrated BI estates from Qlik, SAP BusinessObjects and Looker into governed semantic layers. This comparison is written from that side of the table: what happens to your definitions on the day you want to leave.
What Strategy Mosaic is
Strategy is the company formerly known as MicroStrategy. It made Mosaic generally available on 24 June 2025 and calls it a universal semantic layer: a standalone layer that sits above your databases and warehouses and serves governed definitions to any tool.
The parts that matter for this comparison:
- Semantics from MicroStrategy. Mosaic is built on the same semantic architecture MicroStrategy has used for decades: attributes, hierarchies, level-aware metrics, custom calendars and an enterprise security model.
- Two ways to model. Mosaic Studio for AI-assisted, self-service modeling, including metrics defined in plain language. Mosaic Schema for centrally governed enterprise models. Studio models can map to the Schema.
- Many ways in. Tools reach Mosaic through SQL (JDBC), DAX, MDX, REST, Python and an MCP server, with optimized connectors for Tableau, Power BI, Excel and Google Sheets. Strategy lists 200+ data source connectors.
- An in-memory engine. A query acceleration engine that pushes work down to the warehouse where it can and caches in memory where it helps.
- Governance monitoring. Mosaic Sentinel logs access, flags anomalies and tracks sensitive data across users and AI agents.
The DAX and MDX access is the detail most comparisons skip. It means Power BI and Excel can query Mosaic as if it were a native model. Few standalone semantic layers do that.
Strategy Mosaic vs dbt Semantic Layer
The dbt Semantic Layer is powered by MetricFlow. You define semantic models and metrics in YAML, inside the same dbt project that builds your tables. Tools query those metrics through the dbt platform's Semantic Layer APIs, and the definitions live in your Git repository next to the transformations they depend on.
| Strategy Mosaic | dbt Semantic Layer | |
|---|---|---|
| Where the logic lives | In Mosaic, a vendor platform above the warehouse | In your dbt project, as YAML in Git |
| Who models | Business users in Studio, data teams in Schema | Analytics engineers, in code |
| Access for tools | SQL, DAX, MDX, REST, Python, MCP | Semantic Layer APIs (JDBC, GraphQL) and partner integrations |
| Power BI and Excel | Native via DAX and MDX | Through integrations, not as a native Power BI model |
| Engine | Own in-memory acceleration engine | Generates SQL that runs in your warehouse |
| Enterprise semantics | Hierarchies, multi-form attributes, custom calendars out of the box | Strong on metrics, lighter on hierarchies and calendars |
| Portability | Definitions in Strategy's metadata | Plain YAML; MetricFlow is part of the Open Semantic Interchange effort |
The trade-off is ownership against reach. dbt keeps business logic in your own repository, written by the people who build the tables. Mosaic reaches further into Microsoft tools and gives business users a modeling interface, but the definitions live in a platform you license.
If your data team already works in dbt, adding Mosaic means maintaining metrics in two places unless you are disciplined about which layer owns what. That duplication is exactly the problem a semantic layer is supposed to remove.
Strategy Mosaic vs Snowflake Semantic Views
Snowflake Semantic Views are schema objects inside Snowflake. They describe tables, relationships, facts, dimensions and metrics, and Snowflake's own AI features such as Cortex Analyst use them to answer questions in natural language.
The difference is scope. Semantic Views govern data that lives in Snowflake. Mosaic is designed to sit above several platforms at once: Snowflake, Databricks, BigQuery, SAP, Salesforce and on-premises databases. Strategy's own argument is that a warehouse-native semantic layer keeps you inside that warehouse. That argument is correct, and it cuts both ways: a vendor semantic layer keeps you inside that vendor.
Cost works differently too. Semantic Views come with Snowflake; you pay for the compute your queries use. Mosaic is a separate license on top of your warehouse, which Strategy positions as paying for itself through its in-memory engine reducing warehouse compute.
If your data lives in Snowflake and your AI ambitions run through Cortex, Semantic Views are the shortest path. If you run several warehouses, or expect to move between them, an independent layer starts to earn its license.
Strategy Mosaic vs Looker
Looker's semantic layer is LookML: views, explores, measures and dimensions in code, versioned in Git. It was the first BI tool to make the semantic layer the center of the product, and for many teams it still is the single source of truth.
The limit is that LookML runs inside Looker. Google has opened it up with connectors for other BI tools and an SQL interface, but the definitions are still Looker objects, served by a Looker instance you license.
Mosaic and Looker therefore solve different problems. Looker is a BI tool with a strong semantic layer inside it. Mosaic is a semantic layer that wants to serve every BI tool, including the one you already have. Comparing them makes sense when the real question is: do we want one BI tool with its own semantic layer, or one semantic layer behind several BI tools?
Most organizations I work with say the second, and then buy the first. That gap is where definitions start to drift.
Where should your business logic live?
Strip away the feature lists and you are choosing a home for your business logic. Every option has an owner and an exit cost.
| Home | Tool | You own | Exit cost |
|---|---|---|---|
| Transformation layer | dbt Semantic Layer | The YAML in your repository | Low: readable files, open standard work under way |
| Warehouse | Snowflake Semantic Views | Schema objects in Snowflake | Medium: tied to the warehouse, not the BI tool |
| BI tool | Looker (LookML) | Code, but only Looker runs it | Medium to high: needs translation per tool |
| Independent vendor layer | Strategy Mosaic | Definitions in a licensed platform | Medium to high: depends on export and standards |
None of these is wrong. The mistake is choosing without knowing what you are moving. Most semantic layer projects stall because nobody inventoried the existing logic: the calculated fields, the load scripts, the SQL inside reports. You cannot govern definitions you have not found.
Which semantic layer fits which team
- You run MicroStrategy today. Mosaic is the natural candidate. Your schema objects, hierarchies and security model already speak its language, and you can serve Power BI or Tableau without rebuilding them. With on-premises support for Strategy ending on 31 December 2026, many of these teams are deciding now whether to move to Strategy's cloud, to Mosaic, or away.
- You serve Power BI, Tableau and Excel at the same time. Mosaic's DAX and MDX access is a real advantage here. Test it with your heaviest Power BI reports before you commit.
- Your data team is dbt-first. The dbt Semantic Layer keeps logic next to the transformations and in your own repository. Adding a second semantic layer usually creates the duplication you were trying to remove.
- You are Snowflake-only and building on Cortex. Semantic Views are native, cheap to start and close to the AI features you will use.
- You are on Looker and happy with LookML. Stay, but make the definitions portable. LookML is already code, which makes it one of the easiest semantic layers to translate when the time comes.
What Strategy Mosaic costs
Strategy publishes a starting price: the Standard plan, for teams of 50 to 300 users, starts at $13 per user per month and includes Mosaic Studio and up to 150 GB of in-memory capacity. Enterprise and Government plans are quoted. Strategy says it does not charge for data volume, refresh frequency or AI usage.
The dbt Semantic Layer is part of the dbt platform's paid plans, with usage measured in queried metrics. Snowflake Semantic Views have no separate license; you pay for compute. Looker is licensed per platform plus per user, quoted by Google, with conversational analytics usage billed in tokens above an included monthly allowance.
License price is rarely what decides the total cost. Modeling effort, duplicate definitions and the next migration are where the money goes. A semantic layer that saves 20% on licenses but locks your logic into another proprietary format has postponed a cost, not removed it.
AI agents change the question
All four now expose definitions to AI. Mosaic and Looker offer MCP access, Snowflake feeds Cortex, and dbt's metrics are available to agents through its APIs. An agent that answers "what was revenue last quarter?" with the governed definition instead of guessing from raw tables is the strongest argument for a semantic layer in 2026.
It also raises the stakes. When dashboards disagree, someone notices. When an AI agent answers confidently and wrong because two systems define revenue differently, nobody may notice until a decision is made on it. The semantic layer is the data foundation that prevents that, which is why I keep saying: for every dollar spent on AI, six should go to the data architecture underneath it.
How to decide
- Inventory first. List the definitions you have today and where they live: BI tools, warehouse views, dbt models, spreadsheets.
- Pick the owner. Decide which team owns business logic. Engineers point to dbt or Snowflake. Business-led modeling points to Mosaic.
- Count the consumers. One BI tool or several? Power BI in the mix? AI agents planned?
- Price the exit. Ask every vendor how you would export your definitions, and in what format.
- Prove it on your hardest metric. Not the demo dataset. Your revenue, with your fiscal calendar and your security rules.
At Unwind Data we start every semantic layer project with a Logic Scan: in five working days we extract the business logic from your current tools, map what depends on what and capture the definitions in an open standard. Then you choose Mosaic, dbt, Snowflake or Looker on facts, and your definitions stay yours whichever you pick.
Deep dives on modern data engineering
Semantic layers, modern stacks, and scalable architecture — in your inbox, not in a backlog.
Unwind Data
Speak with a data expert
We've helped scale-ups and enterprises move faster on exactly this kind of work — without the trial and error. Strategy, architecture, and hands-on delivery.
Schedule a consultation