The semantic layer alternative to Cortex Analyst, Genie and dbt, that writes itself
An honest comparison of Snowflake semantic views and Cortex Analyst, Databricks Genie and metric views, the dbt Semantic Layer and Looker, against Rig's context layer: generated from your warehouse, kept current as the schema changes, and governed in every AI tool your team uses.
Someone writes it
Every native option centres on a model a person writes or approves: tables, joins and metrics in YAML, LookML or a semantic view. On a warehouse with thousands of tables, that person is a project.
Someone keeps it true
A renamed column or a new table does not update the file. The definitions drift from the warehouse until an answer comes back wrong and someone goes looking.
It lives in one place
A semantic layer inside one warehouse or one BI tool governs that warehouse or that tool. The AI your team actually uses, Claude, ChatGPT, Cursor, sits outside it.
Snowflake semantic views
A semantic view is a schema-level Snowflake object that holds your business model: logical tables, relationships, dimensions, facts and metrics, governed by Snowflake roles and shareable like any other object. It is now Snowflake's recommended home for a semantic model, replacing the YAML file on a stage that Cortex Analyst used first (YAML still works, for backward compatibility).
Semantic View Autopilot, generally available since February 2026, helps draft a semantic view so you do not start from a blank file. Someone still reviews it and keeps it in step with the warehouse.
What it's good at
- Lives inside Snowflake, so RBAC, sharing and lineage are the ones you already run
- Read by Cortex Analyst, Cortex Agents and Snowflake CoWork, so one definition serves Snowflake's own AI
- Snowflake helped launch the Open Semantic Interchange (OSI) format, so the model format is heading somewhere open
Where it stops
- Describes data in Snowflake. Postgres, a second warehouse or a SaaS API sit outside it
- Governs Snowflake's own AI. Claude, ChatGPT or Cursor pointed at the warehouse need their own access story
- Drift is a maintenance job: a renamed column or new table is a change someone makes to the view
Snowflake Cortex Analyst
Cortex Analyst is Snowflake's natural-language-to-SQL service. It answers questions over structured data in Snowflake, grounded in a semantic view (or a legacy YAML semantic model), and the SQL it writes runs on your Snowflake warehouse. It also powers Snowflake CoWork, the product formerly called Snowflake Intelligence, and Snowflake now points new builds at Cortex Agents.
It is billed per message processed, counting only successful responses, with the warehouse compute for the generated SQL billed separately.
What it's good at
- No new vendor: it is already in your Snowflake account and contract
- Answers from inside Snowsight and CoWork, where Snowflake users already work
- Accuracy tracks the quality of your semantic view, which you control
Where it stops
- Only Snowflake data. A question that needs HubSpot, Stripe or a Postgres replica is out of reach unless it is loaded first
- Only as good as the semantic view behind it, and that view has to be built and maintained
- Answers stop at the answer. Acting on it, an alert, a CRM update, a report, is a separate build
Databricks Genie and Unity Catalog metric views
Genie is Databricks' natural-language interface. What used to be a Genie space is now a Genie Agent: a domain expert curates up to 50 Unity Catalog tables, views or metric views, adds instructions and example SQL, and business users ask questions inside the workspace. The data has to be registered in Unity Catalog.
Metric views are Databricks' semantic layer, defined in YAML (via SQL or Catalog Explorer) and generally available since April 2026 as part of Unity Catalog Business Semantics. They can be queried from SQL, notebooks, dashboards and Genie.
What it's good at
- Unity Catalog permissions, lineage and audit apply without a second governance model
- Metric views are reusable across SQL, dashboards and Genie, and Databricks is open-sourcing the core into Apache Spark
- Curated example SQL gives verified answers to the questions you know people ask
Where it stops
- Unity Catalog data only, and each Genie Agent is capped at 50 tables or views
- Someone curates each agent: instructions, examples and metric views are written and kept current by hand
- Lives in the Databricks workspace. Teams asking in Claude, ChatGPT or Cursor are outside it
The dbt Semantic Layer and MetricFlow
The dbt Semantic Layer defines metrics in YAML alongside your dbt models, and MetricFlow compiles them into SQL for your warehouse. MetricFlow has been open source under Apache 2.0 since dbt Labs announced it at Coalesce in October 2025 (v0.209.0 and later).
The hosted Semantic Layer, the APIs and integrations that BI and AI tools query, needs a dbt Starter or Enterprise account. It supports Snowflake, BigQuery, Databricks, Redshift, Postgres and Trino/Starburst.
What it's good at
- Warehouse-portable: the same metric definitions work across the supported warehouses
- Definitions live in git next to the models, reviewed in pull requests like any other code
- MetricFlow is Apache 2.0, and dbt Labs is a backer of the OSI format
Where it stops
- Every metric, entity and dimension is YAML someone writes. On a large warehouse that is a long project
- Covers what is modelled in dbt. Tables outside the project, and the questions no metric anticipated, are not in it
- The hosted layer is a paid dbt platform feature, and AI tools still need their own permissions and cost controls
BigQuery, Looker and LookML
There is no standalone BigQuery semantic layer product. On Google Cloud the governed semantic layer is LookML, Looker's modelling language, and Looker's Open SQL Interface lets other BI tools query a LookML model as if it were a database.
For natural-language questions Google has two: Conversational Analytics in Looker, grounded in LookML, and Conversational Analytics in BigQuery, generally available since July 2026, which draws context from Knowledge Catalog, verified queries and custom instructions.
What it's good at
- LookML is mature and battle-tested, and many teams already have years of definitions in it
- Looker's Conversational Analytics can query BigQuery and other warehouses through the LookML model
- BigQuery's own assistant needs no Looker licence for ad hoc questions
Where it stops
- The governed layer is a Looker licence and a LookML project someone writes and maintains
- Two assistants, two sources of context: LookML for Looker, catalog and verified queries for BigQuery
- Claude, ChatGPT or Cursor pointed at BigQuery do not inherit either
Side by side
The same questions asked of each option. Vendor rows are from each vendor's own documentation, checked 28 September 2026.
| Snowflake semantic views + Cortex Analyst | Databricks Genie + metric views | dbt Semantic Layer | Looker (LookML) on BigQuery | Rig | |
|---|---|---|---|---|---|
| Where definitions come from | Semantic views, drafted with Autopilot, reviewed by hand | Metric views in YAML, plus instructions and example SQL per Genie Agent | YAML in your dbt project | LookML, written by hand | Generated from schema, query history and existing models, then certified by a person |
| When the schema changes | Someone updates the view | Someone updates the metric view and agent | Someone updates the YAML | Someone updates the LookML | Context re-reads the schema and follows the drift |
| Data it covers | Snowflake | Unity Catalog, 50 tables or views per agent | Six supported warehouses, what is modelled in dbt | Warehouses behind the LookML model | Nine warehouse types plus ingested SaaS sources, several at once |
| Existing semantic layer | Legacy YAML models still work | Build metric views | Is the semantic layer | Is the semantic layer | Imports LookML and Lightdash metrics, exports OSI |
| AI tools it governs | Cortex Analyst, Cortex Agents, CoWork | Genie and Databricks surfaces | Tools that integrate with the dbt SL APIs | Looker's Conversational Analytics | Claude, ChatGPT, Cursor and any MCP client, with one set of permissions |
| After the answer | Answer and chart | Answer and chart | Metric values for the calling tool | Answer and chart | Reports, alerts, CRM updates and workflows |
| Cheapest when | You are all-in on Snowflake | You are all-in on Databricks | You already run dbt and like YAML | You already pay for Looker | Several sources, several AI tools, no one free to write YAML |
What Rig does differently
Rig calls it a context layer rather than a semantic layer, because certified metrics are only the top of it. Underneath sit the table and column meanings, joins and business terms that let an AI answer the question no metric was written for, like chasing one order ID through three systems.
Generated from your warehouse, then kept current
Rig reads the schema, the query history and the models you already have, and drafts the table meanings, joins, business terms and metrics itself. When a column is renamed or a table appears, the context re-reads the schema and follows the drift instead of waiting for someone to edit a YAML file.
Any warehouse, and more than one
Snowflake, BigQuery, Databricks, Redshift, Postgres, SQL Server, MySQL, MotherDuck and Supabase, plus the SaaS sources you ingest. One context layer across all of them, rather than one semantic layer per vendor.
Bring the semantic layer you already have
Import an existing LookML layer with SQL, joins and descriptions intact, or Lightdash metrics from your dbt schema files. Everything lands as a draft to review and certify. Rig stores metrics in the Open Semantic Interchange format and exports it, so the work is never trapped.
Certified metrics and business terms
Metrics move from draft to certified, and a certified definition is protected: an edit arriving from a BI tool surfaces for review rather than silently overwriting it. The same object answers in Claude, in Omni and in your repo.
Permissions set once, enforced in every AI tool
One MCP endpoint for Claude, ChatGPT, Cursor and the rest, with role, schema, column and row-level access enforced per user. Warehouse grants such as Unity Catalog row filters and column masks carry through, and Rig adds its own controls on top.
Sandboxed, cost-checked SQL, then action
Every generated query is validated in a sandbox and cost-checked before it touches your warehouse, and every query is logged by user and by agent. Answers can then drive something: a report, an alert, a CRM update, a workflow.
Context layers in production
Three teams running Rig's context layer over large warehouses, including Snowflake and BigQuery. Every figure below is from their published case study.
A 4,000-table warehouse and four blocked teams. A static semantic layer was not enough, so Rig built a self-healing context layer over the whole estate. Fraud-team pilot to org-wide rollout in 16 weeks.
Read the case studyA managed context layer over Snowflake with certified metrics across sales, revenue and retention, served into Claude. 4,000+ MCP tool calls in the last 30 days and 15+ dashboards and agents in weekly use.
Read the case studyA managed context layer over Novakid's BigQuery warehouse, with sales, marketing and ops teams asking in Claude over Rig MCP.
Read the case study"The result is going to be consistent every single time, and now I can't imagine operating without it."
When the native option is the better choice
Stated plainly, because some of you should close this tab.
You are on one warehouse, you will stay on it, and the questions come from a handful of analysts. The native option is already in your contract and your governance model, and adding a second vendor is a cost you do not need.
Your team is happy writing and reviewing YAML in pull requests. A hand-written semantic layer is slower to build, but every line of it is a decision a person made, and some teams want exactly that.
You have invested in MetricFlow and want the definitions in an open-source engine you run yourself. MetricFlow is open source under Apache 2.0. Rig's format is open too (OSI export), but Rig itself is a hosted product.
Your organisation is standardised on Looker for dashboards and the LookML model is the contract. Rig can import it and serve it to AI tools, but it does not replace Looker as a governed dashboarding tool for hundreds of report consumers.
You need answers from inside the vendor's own UI with no new login. Cortex Analyst in Snowflake CoWork and Genie inside a Databricks workspace sit where your analysts already are. Rig lives in Claude, ChatGPT, Cursor and its own app instead.
Everything else
It includes one. Rig's certified metrics are a semantic layer in the usual sense: a named definition, the SQL behind it, the joins it relies on and the rules that govern it. Rig calls the whole thing a context layer because it also holds table and column meanings, join paths and business terms for the questions no metric was written for.
No. Rig reads your warehouse schema and drafts table meanings, joins and metrics itself, and a person reviews and certifies them. If you want the definitions in a file, Rig exports the whole model as one Open Semantic Interchange (OSI) document and can open a pull request against your repo, so the YAML exists without anyone hand-writing it.
No. Rig imports an existing LookML layer with SQL, joins and descriptions intact, and imports Lightdash metrics from the dbt schema files they live in. Everything arrives as a draft to review and certify. Birdie Care moved its LookML layer across this way. For MetricFlow definitions in the dbt Semantic Layer, there is no one-click import yet: Rig drafts the same metrics from your models and we check them against yours on a call. The semantic layer guide walks through the LookML route.
Yes, and some teams run both. Rig connects to the same warehouse with a read-only identity and queries run on your own compute, so nothing is moved. Analysts can keep the native assistant inside the warehouse UI while the rest of the company asks through Claude, ChatGPT or Cursor over Rig MCP.
Snowflake, BigQuery, Databricks, Amazon Redshift, PostgreSQL, MySQL, Microsoft SQL Server, MotherDuck and Supabase, plus SaaS sources you ingest through Rig. One context layer can span several of them, which is the case the native options are not built for.
Yes. Rig connects read-only, warehouse grants carry through (on Databricks that includes Unity Catalog row filters and column masks), and Rig adds role, schema, column and row-level access of its own. Those rules are set once and apply in every AI tool connected over MCP.
Every generated query is validated in a sandbox and cost-checked before it runs against your warehouse, and oversized scans are blocked. Every query is logged by user and by agent with the SQL attached.
You keep them. Metrics are stored in the shape of the Open Semantic Interchange standard, and stripping Rig's extension block still leaves a complete, valid OSI model you can export at any time. The warehouse and the data were always yours.
Rig against Claude Code, Workato, Palantir, n8n, Glean and building it yourself
Bootstrap one from scratch, or import LookML, step by step
Cost, effort and what changes when you leave per-row pricing
What a Foundry migration looks like on Rig
Ingestion, models and context on one flat price
See the context layer on your own warehouse
Twenty minutes. Tell us which warehouse you are on and what semantic layer you have today, if any, and we will show you what Rig generates from the schema and what would come across from the definitions you already wrote. If the native option suits you better, we will say so.
Twenty-minute call about your warehouse and definitions
Read-only connection, context layer generated from the schema
Your existing metrics imported, reviewed and certified
Vendor capabilities checked 28 September 2026 against Snowflake, Databricks, dbt Labs and Google Cloud documentation. Product names belong to their owners. Customer figures are from Rig's published case studies.