Semantic Layer Capabilities: 
A Framework for Evaluation 

Snowflake Semantic Views provide a native semantic capability within the Snowflake platform, with three constraints relevant to enterprise evaluation. First, they are scoped to a single Snowflake account and do not federate definitions across other platforms or data sources. Second, Snowflake documentation and field reports indicate that Cortex Analyst performs best with relatively narrow semantic models (on the order of 50–100 total columns across all tables) — a threshold that many enterprise data models exceed. Third, structural changes require a full CREATE OR REPLACE operation, and SQL updates overwrite manual Snowsight edits without merging. Strategy Mosaic spans multiple platforms, has no published hard column-count limits and has been validated on materially larger models in customer environments, supports incremental editing, and provides a visual no-code interface for non-technical users. Mosaic can also reduce Snowflake compute costs by caching queries before they reach Snowflake's consumption billing layer. 

dbt MetricFlow is a code-first metrics layer designed for data engineers working in SQL and YAML. It defines and calculates metrics within the dbt transformation pipeline. Strategy Mosaic is a full enterprise semantic layer that includes a visual no-code modeling interface, AI-assisted model authoring, cross-platform federation, enterprise governance and lineage, native MDX support, and AI agent context delivery. From an architectural standpoint, the two tools can be used together in a complementary way: dbt defines and transforms the underlying data tables, while Mosaic governs the semantic definitions built on top of those tables. Mosaic integrates natively with dbt projects. 

Yes. Strategy Mosaic integrates with Databricks Unity Catalog. Unity Catalog provides governance and lineage within the Databricks platform, covering tables, schemas, and access control scoped to the Databricks perimeter. Mosaic extends that governance into a semantic layer that spans Databricks alongside other data platforms in use. Semantic governance in Unity Catalog is bounded by the Databricks account; Mosaic's governance is not bounded by any single platform. Mosaic can reduce Databricks Unit (DBU) consumption by caching frequently executed queries before they reach Databricks compute, depending on workload patterns and cache configuration. 

Yes. Strategy Mosaic can build semantic models on top of Apache Iceberg tables exposed through supported query engines (such as Databricks, Snowflake, or other compatible engines), without requiring knowledge of the underlying file format or storage specification. Metric definitions in Mosaic remain platform-agnostic regardless of whether the underlying data is stored in Iceberg, Parquet, or a proprietary warehouse format, which allows infrastructure changes to occur without requiring metric redefinition. 

AI agents and large language models that query data warehouses directly have no access to the business context that governs how data should be interpreted. Without a definition of which "Revenue" calculation is authoritative, or what qualifies as an "Active Customer" for a given organization, a model will produce results that are computationally valid but may be semantically inaccurate. A semantic layer provides governed business definitions to AI agents through the same interface it provides to human-facing BI tools, ensuring consistent interpretation across all consumption layers. As AI adoption expands, the number of agents and automated workflows requiring this context increases proportionally. 

Strategy Mosaic uses named-user (per-seat) pricing with no per-metric, per-object, or consumption-based charges. AtScale uses a Deployed Semantic Object (DSO) model in which each metric and attribute deployed to production incurs a charge, meaning licensing costs scale linearly with the breadth of the semantic layer. Cube.dev pricing scales with API usage volume. With Mosaic's model, the number of metrics or attributes deployed does not affect licensing cost, which is relevant when evaluating total cost of ownership as semantic layer scope expands over time. 

A metrics layer is a capability focused specifically on metric definitions and calculation logic. Tools such as dbt MetricFlow operate as metrics layers — they handle how measures are computed but do not provide broader governance, cross-platform federation, lineage, or AI context delivery. A semantic layer is a broader layer that includes metric definitions but also encompasses hierarchies, relationships between business concepts, ownership, version history, change management, and the infrastructure to deliver those definitions consistently to every consumption tool and agent. For purposes of this paper, “headless BI” refers to an architectural pattern in which metric definitions are decoupled from visualization tools and exposed via API, enabling any application, tool, or AI agent to query the same governed definitions. Strategy Mosaic supports headless BI API consumption while also providing a native visual interface for users who do not interact via API. 

Trino is a distributed SQL query engine that solves the connectivity problem: enabling fast, federated queries across multiple data sources — object storage, relational databases, data lakes — without physically moving data. That is data virtualization. 

A semantic layer solves a different problem. When multiple BI tools or AI agents query through Trino, each can still apply its own calculation logic for shared metrics like Revenue or Active Users. A semantic layer sits above Trino, governing the business definitions that get applied to those federated results and enforcing consistent interpretation across all consumers. 

The two are architecturally complementary. Strategy Mosaic can use Trino as an underlying query and federation engine while providing the semantic governance layer above it — combining Trino's cross-source performance with governed metric definitions, lineage, and AI context delivery. Mosaic's in-memory caching layer can also reduce the volume of queries that reach Trino compute, lowering infrastructure cost at scale.