dbt Labs open sources dbt Charts, a YAML language for agent-built dashboards
- dbt Labs open sourced dbt Charts under Apache 2.0, a declarative YAML dialect in which one file declares a complete interactive dashboard, so dashboards written by a chat agent stay readable and auditable.
- The pitch targets the failure mode of agent-built reports: by default an agent scatters HTML, CSS, JavaScript, chart libraries and a React or Streamlit app across many files, which is slow to audit and burns tokens on every edit, while BI copilots only allow what their UI exposes.
- SQL still declares what data, YAML declares how it looks; the file holds over 1,100 config options across 16 chart types plus composed charts built from them, and styles cascade from chart to board to theme, with boards able to
extends:another board. - The CLI (
dct render,dct serve) renders boards to SVG, HTML, PNG, PDF or the terminal on a laptop or in CI, and runs on top of vega-lite, which dbt Charts wraps with dashboard structure, SQL queries and opinionated styling. - With a dbt project, the
charts/directory sits besidemodels/in the same Git repo so a model change and its charts ship on one branch; the tool ships separately while in preview but will land in the dbt CLI soon.
Hacker News opinions
Hi HN, I'm Dave, founder of Chartio, now announcing dbt Charts: an open source YAML dialect and tool for declaring and rendering dashboards. When you make dashboards with Claude or other agents you get a lot of free-form artifacts that are hard to audit and scale, so we wanted something like markdown but for dashboards. Apache 2.0, launched today alongside dbt.
Congrats on the launch. I was wondering who was going to make a run at being the industry standard here. Hope it gets adopted widely.
Good to see something built for AI that backs both openness and interpretability. Most of what agents produce for charts right now is vibe coded JS slop, and this at least gives artifacts that are readable, maintainable and render the same dashboard deterministically, just with fresh data.
Yup, that's exactly the idea.
Unbundling BI is where things are headed now that everyone has coding agents. I'm already treating email as a BI problem: ETL it out of Gmail, build different views and reports over it. The natural followup is how to visualize that data in chat, and the dbt table component looks like it could help.
The agent experience is surprisingly good. I told it to build a dashboard of my hiring inboxes (candidate name, email, locale, application quality, response age) after uv tool install dbt-charts && dct skills intro, and the one-shot output was better than I expected.
Pair this with something like bento for slide decks and you get a real path away from walled gardens and proprietary suites.
Honestly I keep wondering why we visualize data at all. Charts always felt like showing your work in math class, a forced synesthesia. The context should be the focus: rocket must land at less than 0.2 mps, pump the telemetry into that filter, and reduce velocity or show green.
Is this associated with dbt Labs?
Yes, it's a dbt product. It'll be in the dbt CLI soon, we shipped it as a separate tool first while it's in preview.
Everyone wants a clever One Spec to Rule Them All for generative UI, and my bet is the bitter lesson still bites. Models keep getting faster at one-shot writing things from scratch with primitive libraries, and that flexibility will make all of this moot.
It's a fairly domain specific spec, we deliberately avoided going generic. Raw HTML/SVG might well win out, but then it's hard or impossible for a human to verify where the numbers on a chart came from. A DSL keeps consistency, lowers maintenance and saves tokens, and the structured format is what makes it readable and testable.
It's neat but pretends to be more innovative than it is. BI has already been decoupled from everything else, people generate Excel and Power BI reports with AI, and YAML versus JSON versus XML doesn't matter when the model writes whatever you ask for. Good idea, will be popular in some circles, but hiring a real data designer still matters because visualization is easy to get wrong.
AI can generate whatever you tell it, sure, but what do you do with the artifact afterwards? If all you can do is hand the YAML back to the agent and say make a chart from this, you get a vastly different chart than the first time. Reuse needs a well-defined structured language.
I don't think Dave is claiming a paradigm shift. The claims are that it uses old established visualization patterns from before BI tools took over, which produces consistently good charts, and that it's simple and maintainable. Plenty of tools are just well executed points in the known design space. (I work at dbt/Fivetran.)
I was building something similar, where visuals are reusable artifacts that external services know how to render and agents in Slack or other harnesses receive the spec from the service. How does this differ from vega-lite?
We use vega-lite under the hood. Vega-lite is a vast toolbox for assembling charts from static data, and dbt Charts adds a whole layer on top: dashboards with repeatable SQL queries plus opinionated styling. A unified charting spec all agents emit would be the dream, but it would have to be simple and extremely versatile at the same time, and I'm not sure that combination exists yet.
How does this compare with Evidence?