Visivo vs dbt™ Charts: An Honest Comparison

This fall, dbt Labs released dbt™ Charts as a public beta, an open source YAML language for dashboards with a CLI called dct. It is a serious project. It is Apache 2.0, it is pitched as "easy for agents to write, easy for humans to audit," and it already ships agent skills, a local MCP server, PR validation and a hosted platform.

Visivo is also dashboards as YAML, built for agents and for review. So people ask us how the two compare. This post is our answer. We build Visivo, so read it with that in mind. We have tried to state every dbt™ Charts fact from its own README, docs and changelog, as of version 0.10.0 (October 19, 2026). It is pre-1.0 and moves fast, so check those pages for anything newer.

The short answer

Both tools agree on the big idea: a dashboard is a text file in Git that an agent can write and a person can review in a pull request. Tristan Handy made the case for this shape in BI's Second Unbundling. We agree with most of that essay.

The difference is where the business logic lives.

• dbt™ Charts puts SQL in the board. Each board declares its queries, and each chart reads a query. Inside a dbt™ project, those queries read your models with ref().
• Visivo puts a semantic layer under the board. You define metrics, dimensions and relations once, on the database you already have, and every chart, teammate and agent reuses those definitions.

If your logic already lives in dbt™ models and you want boards in the same pull request, dbt™ Charts is a natural fit. If you want governed metrics on Postgres, DuckDB or another source without standing up more tooling, that is what Visivo is for.

What dbt™ Charts is

From its README: dbt™ Charts "compiles YAML board definitions into interactive dashboards and reports in many formats. SQL is still the language for defining WHAT data you want to see, and dbt Charts wraps that with a simple YAML syntax declaring HOW you want to see it."

Some facts worth knowing:

• A dbt™ project is optional. The README says so directly: charts/ "can stand alone and query your warehouse directly." Inside a dbt™ project you get ref(), your dbt™ profile as the connection, and dct impact <column> to find which boards a column change breaks.
• Wide warehouse coverage. CSV, Parquet, JSON and DuckDB locally, plus Athena, BigQuery, ClickHouse, Databricks, PostgreSQL, Redshift, Snowflake, Spark and Trino, mostly through dbt™ adapters.
• Many output formats. dct serve gives a live board with working filters. dct render writes HTML, PDF, PNG, SVG, JSON, and even terminal output. Charts render with Vega-Lite.
• Built for agents. dct skills chart hands an agent the YAML reference, dct init mcp wires a local MCP server into your editor, and the hosted platform has a remote MCP connector for Claude and ChatGPT.
• Validation in CI. dct init ci writes a GitHub Actions workflow that runs dct validate on every pull request, with no warehouse credentials.
• A hosted platform. dbt™ Charts Cloud adds access control, a visual editor, AI chat and git-backed editing. Its pricing page lists a free Individual plan for up to three collaborators, and a per-seat Team plan that is not priced yet.
• Read-only mirror. The GitHub repo mirrors a private upstream. Issues are welcome; pull requests are closed unmerged.

Semantic layers: the real difference

Here is the same chart in both tools: net revenue by month.

In dbt™ Charts, the calculation is SQL inside the board:

queries:
  revenue:
    source: warehouse
    sql: |
      SELECT DATE_TRUNC('month', created_at) AS month,
             SUM(amount - refunds) AS net_revenue
      FROM {{ ref('orders') }}
      GROUP BY 1

charts:
  revenue_trend:
    query: revenue
    type: bar
    x: month
    y: net_revenue

rows:
  - revenue_trend

That is clear and easy to review. The cost shows up on the tenth board. If net revenue is defined in the query, each board that shows it carries its own copy, and the copies can drift. The dbt™ answer is to push that logic down into a dbt™ model, which works well if you run dbt™.

In Visivo, the metric is defined once on the model, and the chart only names it:

models:
  - name: orders
    sql: SELECT * FROM orders
    metrics:
      - name: net_revenue
        expression: "SUM(amount - refunds)"
        description: "Revenue after refunds"
    dimensions:
      - name: order_month
        expression: "DATE_TRUNC('month', created_at)"

insights:
  - name: revenue-by-month
    props:
      type: bar
      x: ?{ ${ref(orders).order_month} }
      y: ?{ ${ref(orders).net_revenue} }

Every insight that needs net revenue references net_revenue. Change the definition once and every dashboard follows. Declare a relation between orders and users, and Visivo writes the join when an insight uses fields from both. This works on any of Visivo's ten sources, including Postgres, MySQL, SQLite and DuckDB, and it does not need dbt™ or a separate semantic layer service.

To be fair about where dbt™ Charts is going: its docs say that querying the dbt™ Semantic Layer by metric name "is planned" (issue #1). Its development builds also add semantic queries through MetricFlow bundles, with AGG() over declared calculations and an option that forces every query through the bundle. That is not in the 0.10.0 release yet, but expect it soon. dbt Labs owns MetricFlow, so if your team already defines metrics there, dbt™ Charts will likely be the shortest path to charts on top of them.

The question for you is not "which tool has a semantic layer." It is where you want your metric definitions to live. If that answer is "in our dbt™ project, in MetricFlow," watch dbt™ Charts closely. If the answer is "next to the dashboards, on the database we already run," that is Visivo's semantic layer.

Agents: both tools are built for them

Both tools ship agent skills and an MCP server, and both are designed so that an agent writes YAML that a person reviews.

The difference is in what an agent edits and how the edit lands.

• In dbt™ Charts, an agent writes board files with the CLI or the MCP tools, and dct validate catches structural errors with a file, line and suggested fix. On the hosted platform, the Claude and ChatGPT connector lets people chat with boards and the warehouse without a local checkout.
• In Visivo, an agent connects to visivo serve over MCP, or you use the built-in Agent tab. It reads your sources, models and metrics, validates its changes, and writes them as drafts. It has no tool to commit, deploy or delete. You review the built result in the Workspace and choose to commit or discard. Because the agent works through the same metrics as everyone else, it cannot quietly invent its own definition of revenue. More on this on the AI readiness page.

Side by side

Where dbt™ Charts is the better pick

We would rather you pick the right tool than the wrong one. dbt™ Charts is likely the better choice when:

• Your team lives in dbt™. Boards next to models/, ref() in every query, and dct impact before a column rename is a tight loop. A model change and the boards that read it ship in one pull request.
• You run Databricks, Athena, Trino, Spark or SQL Server. dbt™ Charts reaches them through dbt™ adapters. Visivo does not support those today.
• You need static exports. PDF, PNG and SVG renders of a board are built in, which suits scheduled reports and docs sites.
• You plan to use MetricFlow. If your metrics will live in the dbt™ Semantic Layer, dbt™ Charts is where that integration is being built.
• You want a permissive license. Apache 2.0 is simpler for some companies than GPL-3.0.
• A small team wants free hosting. The free Individual plan covers up to three collaborators.

Where Visivo is the better pick

Visivo is likely the better choice when:

• You want a semantic layer on the database you already have. Postgres, MySQL, SQLite, DuckDB, CSV or Excel, with metrics, dimensions and relations defined once and no extra service. See sources and dbt™.
• Agents and teammates must use the same numbers. An agent works through your metrics, and its changes wait as drafts until a person commits them.
• You want to edit visually and in YAML. visivo serve has a Workspace for building insights and dashboards by hand, and every change lands in the same YAML.
• You want to ship anywhere. visivo dist packages interactive dashboards as a static bundle for S3, GitHub Pages or an internal file share. Visivo Cloud adds hosting, version history, teams and roles.
• You do not run dbt™, or do not want your dashboards tied to it. Visivo works the same with or without it.

Can you use both?

Yes. Nothing stops a team from keeping dbt™ for transformation, using dbt™ Charts for boards that sit next to models, and using Visivo where a governed semantic layer matters most. Visivo can import your dbt™ models and profiles as Visivo models and sources, so the two can read the same tables.

Try Visivo

The CLI is free and open source. Install it, point it at a database, and define your first metric:

pip install visivo
visivo init
visivo serve

Start with Get started, read how the semantic layer works, or see the pricing for Visivo Cloud. If you are comparing tools for your team and want to talk it through, we are glad to help, including when the answer is dbt™ Charts.