dbt put metrics in YAML. Kater puts them in the SQL you already have.
The dbt Semantic Layer defines metrics for other tools to query. Kater defines them in SQL, and adds the dashboards, apps and answers that read them. You do not have to replace your dbt metrics. When you move one, you do not redefine it. Paste the SQL dbt compiled, and wrap its columns in MEASURE.
You want to bring your dbt models as they are, without redefining a metric.
You want dashboards, apps and answers in Slack, Claude or ChatGPT on the same metrics.
You want tests that check the numbers a metric returns.
Your warehouse is Snowflake or DuckDB.
Stay with the dbt Semantic Layer if
You want your metrics to stay inside your dbt project.
Your BI tools already query the Semantic Layer through its integrations.
Your warehouse is BigQuery, Databricks, Redshift, Postgres or Trino.
Why teams leave the dbt Semantic Layer
01
Metrics are YAML.
Metrics are YAML in your dbt project, with SQL in expression strings and Jinja in filters. In January 2026, dbt Labs changed the spec to make metrics easier to define.
“My issue with DBT is it is a mix of SQL, yaml, jinja2 flow controls (and metrics is whole another thing).”
In Kater
Kater SQL is your warehouse’s SQL with DIMENSION, MEASURE and EVAL. Your agent writes it, and anyone who reads SQL can review it.
02
Each query of a metric counts toward a limit.
The APIs and integrations need a paid dbt plan. Each metric in a successful request counts toward a monthly allowance: 5,000 on Starter and 20,000 on Enterprise.
In Kater
A Kater test checks a query’s rows, or compares a measure with SQL you trust, such as your dbt mart. Tests run after each sync.
04
dbt has no dashboard that reads them.
The Semantic Layer serves metrics to other tools. To see a chart, you connect a BI tool through an integration. dbt Charts, in public beta since September 2026, runs SQL and does not read the Semantic Layer yet.
In Kater
Dashboards and apps in Kater read the same measures. People also ask their own agent in Slack, Claude or ChatGPT.
Kater vs dbt Semantic Layer at a glance
Kater and dbt Semantic Layer, feature by feature
Feature
Kater
dbt Semantic Layer
Building with agents
Source of truth
Yes.Files in git: models, queries, charts, dashboards and apps. Every save is a commit.
In part.Metrics are YAML in your dbt project. Charts and dashboards live in whichever BI tool reads them.
Coding agents
Yes.Claude Code, Codex and Cursor edit the files through the Kater MCP, or in a local copy.
Yes.Agents edit the YAML in your dbt project. The dbt MCP server lists metrics and queries them.
Checks on changes
Yes.A write through the MCP compiles first and is refused on error. Every change has a diff, History and Undo.
In part.dbt validates each semantic model and metric. It checks the definitions, not the numbers.
Answers in your own AI
Yes.People ask in Slack, Claude or ChatGPT. The agent sees only what that person can see.
In part.Agents query metrics through the dbt MCP server, with a dbt platform token. dbt Wizard answers in the dbt platform, in preview.
Metrics and trust
Semantic layer
Yes.Kater SQL: your warehouse’s SQL with DIMENSION, MEASURE and EVAL. Defined once, read everywhere.
Yes.YAML in your dbt project, with SQL in expression strings: simple, ratio, cumulative, derived and conversion metrics.
Built on any SQL
Yes.Any query in your warehouse’s SQL, with its CTEs and window functions. Paste the SQL dbt compiled, and wrap its columns.
In part.Each semantic model sits on one dbt model. Other SQL must become a dbt model first.
Tests on numbers
Yes.Tests check a query’s rows, or compare a measure with SQL you trust. They run after each sync.
No.dbt tests check the models a metric reads. No test checks the numbers a metric returns.
Lineage
Yes.Lineage traces each field through every CTE to the warehouse columns it reads.
In part.Catalog shows lineage between models and metrics. Column-level lineage needs Enterprise.
Dashboards and apps
Dashboards
Yes.Dashboards on the same measures, built by your agent or in the browser.
No.None that read the metrics. A BI tool queries them through an integration.
Apps and reports
Yes.HTML apps, reports and decks on live queries, built by your agent. Export to PDF, PowerPoint, Word or Excel.
No.None. Exports write a saved query to a table in your warehouse on a schedule.
Build without code
Yes.Select fields, a chart and a place on the dashboard, all in the browser.
In part.dbt Insights queries metrics in the browser. It is in beta, on Enterprise plans.
Platform
Warehouses
In part.Snowflake and DuckDB today.
Yes.Snowflake, BigQuery, Databricks, Redshift, Postgres and Trino.
Price per query
Yes.No charge per query, per viewer or per dashboard.
In part.Starter includes 5,000 queried metrics a month, and Enterprise 20,000.
Open source
No.Not open source. Your content is files you can clone and keep.
In part.MetricFlow is open source. The APIs and integrations need a paid dbt plan.
Where the dbt Semantic Layer is ahead
The dbt Semantic Layer does some things better today. Here is each one, and why teams still
select Kater.
Where the dbt Semantic Layer is aheadWhy teams still select Kater
Integrations with BI tools
Power BI, Tableau, Google Sheets, Excel, Hex, Mode, Sigma and others query dbt metrics through an integration.
Why teams still select Kater
Kater has no connector to other BI tools. It has its own dashboards and apps on the same measures, and any agent reads them through the Kater MCP. Keep your BI tool beside it.
Open source
MetricFlow, the engine under the Semantic Layer, is open source under Apache 2.0. You can run it from the command line for free.
Why teams still select Kater
Kater runs the platform for you, so there is nothing to host or upgrade. Your content is still files in git that you can clone and keep.
Metrics beside your models
Your metrics live in the same dbt project as your models, and ship in the same deploy.
Why teams still select Kater
Kater reads the tables dbt builds and the SQL it compiles. Your dbt project keeps running as it does today.
More warehouses
The dbt Semantic Layer connects to BigQuery, Databricks, Redshift, Postgres and Trino. Kater connects to Snowflake and DuckDB today.
Why teams still select Kater
Kater goes deep on each warehouse it supports. Queries run live, and the compiler checks each SQL dialect before a query runs. Have a warehouse we do not support? Request it.
The APIs and integrations need a paid dbt plan. Starter is $100 per user a month, with 5,000 queried metrics a month. Enterprise is quoted, with 20,000. Each metric in a successful request counts. MetricFlow is free to run from the command line.
Kater
A 30-day free trial with every feature, then a subscription quoted for your team. Kater does not charge per viewer or per dashboard. Kater runs no chat of its own, so answers run in the agent your team already uses.
Moving from the dbt Semantic Layer
You do not have to move your dbt metrics. Keep them in dbt, and add Kater beside them. When you move one, you do not redefine it. Paste the SQL dbt compiled for its model into Kater, and wrap the columns in DIMENSION and MEASURE. The CTEs keep their dbt names, so lineage traces every measure back through each model it reads.
What each dbt Semantic Layer object becomes in Kater
In the dbt Semantic Layer
In Kater
dbt model
The SQL dbt compiled, pasted into a Kater model
Semantic model and its dimensions
Semantic model, with DIMENSION on each column
Entity
RELATIONSHIP join, checked on your warehouse
Simple metric
MEASURE around its aggregate, such as SUM(spend)
Ratio and derived metrics
A MEASURE that reads other measures with EVAL
Offset window, such as the same month last year
EVAL with SET, such as SET(month = CURRENT(month) - INTERVAL 1 YEAR)
Saved query
Query file
dbt test
Kater test, including same_as checks against your dbt marts
-- The SQL dbt compiled for ad_reporting__campaign_report.
WITH __dbt__cte__int_ad_reporting__campaign_report AS (
SELECT ... FROM kater_dataset.facebook_ads__campaign_report
UNION ALL
SELECT ... FROM kater_dataset.google_ads__campaign_report
UNION ALL
SELECT ... FROM kater_dataset.tiktok_ads__campaign_report
), base AS (
SELECT * FROM __dbt__cte__int_ad_reporting__campaign_report
)
SELECT
DIMENSION('platform', base.platform) AS "Platform",
DIMENSION('union__campaign_name', base.campaign_name) AS "Campaign Name",
MEASURE('sum__spend', SUM(spend)) AS "Spend",
MEASURE('sum__conversions', SUM(conversions)) AS "Conversions"
FROM base
GROUP BY 1, 2
A model from Fivetran’s ad_reporting dbt package, in Kater. The CTEs hold the SQL dbt compiled, under their dbt names. DIMENSION and MEASURE wrap the columns the model already had, so lineage traces Spend back through each CTE to the Facebook, Google and TikTok tables.
Ask your agent to move one model at a time. A same_as test compares its numbers with your dbt mart, so you know they match.
No. Keep them in dbt for the tools that read them, and add Kater beside them. Move a metric to Kater when you want to.
How do we move a dbt metric to Kater?
Paste the SQL dbt compiled for its model into Kater, and wrap the columns in DIMENSION and MEASURE. A ratio or derived metric becomes a MEASURE that reads other measures with EVAL. A same_as test then checks the numbers against your dbt mart.
Does Kater keep lineage to our dbt models?
Yes. The CTEs keep their dbt names, and lineage traces each measure through every CTE to the columns it reads. Your agent reads the same SQL, so it sees where each number comes from.
Do we need dbt for Kater?
No. Schema sync writes a file for each warehouse table, and you model on top of it in Kater SQL. If you use dbt, Kater reads the tables it builds.
Can we keep the dbt Semantic Layer and add Kater?
Yes, for as long as you want. Both read the same warehouse. Keep your dbt metrics for the BI tools that query them, and add Kater for dashboards, apps and answers in your team’s own agent. Move a metric when you want, and compare its numbers with dbt first.