Why does the category look different in 2026?
Until 2023, "semantic layer" meant a BI feature: a metric definition that a dashboard could resolve. Three things changed that. First, AI agents began issuing thousands of queries per hour against the same warehouse. Second, the warehouses themselves shipped first-party text-to-SQL surfaces (Snowflake Cortex Analyst, Databricks AI/BI Genie). Third, regulated industries discovered that retrieval-only architectures cannot pass audit. The result: at least four distinct products now compete for the same word, and the right one for your stack depends on which problem you actually have.
What should you actually evaluate?
Five criteria predict whether a semantic layer survives contact with AI workloads. Score each 0-5.
- Graph autonomy - does the platform auto-build the semantic graph from your data sources, or do you hand-author every entity and relationship? Manual scores 0; autonomous detection plus drift handling scores 5.
- Dialect coverage - how many SQL dialects does the compiler support natively? 1-3 dialects scores 1; 10+ with dialect-perfect output scores 5.
- Compile-time governance - are RBAC, ABAC, and row/column-level predicates enforced at compile time, or applied as a post-query filter? Post-filter scores 1; compile-time injection scores 5.
- AI-agent readiness - can agents call the platform via HTTP, JDBC, or an MCP-style tool surface? Does the platform return proven join paths and an audit trail per query? Manual SDK scores 1; full agent surface with proofs scores 5.
- Audit trail and reproducibility - can you re-run a historical query and prove it used the exact definitions in force at that moment? None scores 0; point-in-time reproducible scores 5.
The full evaluation rubric and worked example live on the pillar guide.
What does Cube do well, and where does it stop?
Cube (formerly Cube.js) is the developer-first metrics API. You define metrics and dimensions in YAML or JavaScript; Cube exposes them through REST, GraphQL, and SQL APIs. It is the lightweight pick when your consumers are mostly applications and dashboards and your data team is happy hand-authoring metric definitions.
Where it stops: there is no autonomous graph, no dialect-perfect compiler across 16+ engines, and no compile-time governance for AI agents. Read the Colrows vs Cube comparison.
What does Looker do well, and where does it stop?
Looker (now Google Looker) is the long-running enterprise BI semantic layer, built on LookML. It encodes business meaning for dashboards and explores with strong governance inside the BI surface. If your AI strategy is "agents call our existing Looker explores", it is the natural choice.
Where it stops: LookML is hand-authored at scale, the dialect surface is BI-centric, and governance is dashboard-scoped rather than compile-time across every consumer. Read the Colrows vs Looker comparison.
What does the dbt Semantic Layer do well, and where does it stop?
The dbt Semantic Layer (powered by MetricFlow) defines metrics on top of dbt models and serves them through a query API. It is the right pick when dbt is already the source of truth for transformations and you want metric definitions to live next to the models.
Where it stops: it is a metric API, not a runtime; there is no autonomous graph beyond dbt-defined entities, no compile-time governance for AI agents, and no dialect-perfect SQL across non-warehouse sources. Read the Colrows vs dbt Semantic Layer comparison. Existing dbt metric definitions can be ingested into Colrows as a starting point.
What does AtScale do well, and where does it stop?
AtScale is the virtual OLAP-cube semantic layer. It serves multidimensional analytics workloads at speed and is the right pick for organisations standardised on tools that consume OLAP.
Where it stops: the cube model is not the typed graph that AI agents need for proven join paths, and the agent surface is not first-class. Read the Colrows vs AtScale comparison.
What does ThoughtSpot do well, and where does it stop?
ThoughtSpot is search-driven analytics with Sage AI for natural-language questions. It is a strong pick when the goal is end-user search across well-modelled tables.
Where it stops: the semantic model is BI-application-scoped, not an infrastructure layer that other agents and applications compile through. Read the Colrows vs ThoughtSpot comparison.
What does Snowflake Cortex Analyst do well, and where does it stop?
Cortex Analyst is Snowflake's text-to-SQL service. Its YAML semantic model is the right pick when your entire analytical surface lives inside Snowflake. Snowflake's own 2025 launch of the Open Semantic Interchange (OSI) initiative concedes that semantics belong above any single warehouse.
Where it stops: it sees only data inside Snowflake; the YAML semantic model is hand-maintained; and there is no cross-estate graph. Read the deep-dive on warehouse-native semantic layers.
What does Databricks Genie do well, and where does it stop?
Databricks AI/BI Genie is the conversational analytics surface on Unity Catalog. It is the right pick when your data is governed inside Databricks and queries are structured-only.
Where it stops: Genie is structured-data only; the documented limit is 30 tables per Genie Space; Unity Catalog governance ends at the Databricks boundary. Read the deep-dive.
Where does Colrows fit?
Colrows is the semantic execution layer: a runtime that compiles enterprise intent into governed, deterministic, dialect-perfect SQL across 16+ engines. The graph is autonomously built and continuously maintained. Compile-time RBAC, ABAC, and row/column-level predicates are injected before any SQL leaves the planner. Every query produces a point-in-time reproducible audit trail. Read the 7-step pipeline walkthrough and the full pillar guide.
Which semantic layer should you choose in 2026?
Match the product to the problem. If your consumers are mostly humans inside one BI tool, the BI semantic layer is fine. If you live entirely inside Snowflake or Databricks and your queries are structured-only, the warehouse-native surface is the simplest answer. If your AI strategy depends on agents that issue thousands of queries per hour across multiple sources, with regulated audit and governance, the only structurally-correct answer is a semantic execution layer. Talk to us if your stack falls in the third bucket.