7 ms·

Charts built for Chat

295 points by thingsilearned 13d ago

thingsilearned 13d ago
Hi HN, I'm Dave the founder of Chartio (YC'10 now Atlassian Analytics), announcing today dbt Charts, an open source YAML dialect and tool for declaring and rendering dashboards. When making dashboards with claude or other agents, a lot of free-form artifacts are created that makes it hard to audit and scale. dbt Charts is a simple YAML dialect that declares and renders a chart (think markdown but for dashboards). Along with dbt its Apache 2.0 and launched today. We hope this language + AI help make the BI space more open with dashboards as concise auditable code. Would love any thoughts and feedback.
- mceoin 13d ago
  Congrats on the launch Dave! I was wondering who was going to launch an attempt at industry standard here. Hope it gains widespread adoption.
  - thingsilearned 13d ago
    Thank you Eoin!
- iamcreasy 13d ago
  Thank looks cool. Do you guys have plan to add interactivity to these charts? Will it be possible to inject JS in these charts?
  - thingsilearned 12d ago
    re: interactivity We already have variables and links (which work with variables)[1]. Variables create interactive menus that update urls, queries and charts. If you have a variable `region` and you set it the url will add a get param ?region=<value> Each chart also has a basic `link:` property can use to link to the existing or other urls with the variables set. For example type: bar x: revenue y: region link: '?region={{ region }}' The result is a big range of flexibility, for example [2] here's an example of Conways Game of Life inside of dbt Charts. [1] variables example - https://play.dbtcharts.com/?example=variables%2Fall-input-types.yml https://play.dbtcharts.com/?example=variables%2Fall-input-ty.... [2] Conways game of life - https://play.dbtcharts.com/?example=variables%2Fgame-of-life.yml https://play.dbtcharts.com/?example=variables%2Fgame-of-life...
fletchrichman 13d ago
This looks great can’t wait to try it out
marojejian 13d ago
Nice to see something built for AI that's supporting both openness and interpretablilty.
mollifier14 13d ago
A beacon of hope between all the vibe coded JS slop charts and dashboards! I love that this creates artifacts that are readable, maintainable and reproduce the same dashboard consistently (deterministically!), just with fresh data.
- thingsilearned 13d ago
  Yup, that's exactly the idea.
nzoschke 13d ago
This looks great. "Unbundling BI" is absolutely where things are headed now that more people have agents, coding agents, agent computers to help with work. I'm seeing this all up and down knowledge work tools. I've started treating email as a BI problem -- ETL it from Gmail and and create many different views into it and reports from it. I just wrote up some thoughts on that here: https://housecat.com/blog/making-gmail-data-fast-for-humans-and-agents https://housecat.com/blog/making-gmail-data-fast-for-humans-... A natural followup is how to better visualize this data in chat. The DBT table component looks like it could help https://docs.dbtcharts.com/charts/tables/ https://docs.dbtcharts.com/charts/tables/
- nzoschke 13d ago
  Wow https://github.com/dbt-labs/dbt-charts https://github.com/dbt-labs/dbt-charts has a great chat user / agent coding experience: > Make charts of this with dbt Charts. Start with: uv tool install dbt-charts && dct skills intro > > build a dashboard of my hiring inboxes: list of candidate name / email / locale, application quality, response age The one-shot dashboard is surprisingly good.
- stackghost 13d ago
  >This looks great. >"Unbundling BI" is absolutely where things are headed now that more people have agents, coding agents, agent computers to help with work. Agreed. Coupled with bento[0] for slide decks, I think this type of project is a very welcome development, helping us move away from walled gardens and proprietary software suites. [0] https://github.com/nyblnet/bento https://github.com/nyblnet/bento
  - nzoschke 13d ago
    Thanks for sharing this too. It reminds me of GistDeck a super old project that turned a gist into slides. Infinitely better than powerpoint or GSlides. https://github.com/nzoschke/gistdeck https://github.com/nzoschke/gistdeck
- pizzafeelsright 13d ago
  Why visualize data? Graphs and charts always felt like the "show your work" in math class. It is forced synesthesia. The rocket either lands or doesn't, safely, as expected. Green and Red lights are abstracted data plots. The context should be the focus. "Rocket must land at less than 0.2/mps" and pump the data into that context filter, more - reduce velocity, less - green light.
xnx 13d ago
Is this associated with dbtlabs?
- georgewfraser 13d ago
  Yes this is a dbt product - will be in the dbt cli soon, we shipped it initially as a separate tool while it’s in preview.
ramesh31 13d ago
Everyone wants to come up with a clever One Spec to Rule Them All for generative UI. My bet is that the bitter lesson still bites. Models will continue getting faster and more error free at single-shot writing things from scratch with primitive libraries, and the flexibility that allows will make all of this for naught.
- thingsilearned 13d ago
  So this is a fairly domain specific (dashboards) spec and we intentionally avoid getting too generic. The raw HTML/SVG or base libraries approach may well win out, but it does make it quite hard or impossible for humans to follow along and verify for instance where the numbers on a chart came from. I think in a future where AI's doing all that verifying (or we just trust it), the AI might still prefer to use a DSL like ours because the abstraction maintains consistency, lowers maintenance, and saves a lot of tokens. But the most helpful bits of a structured DSL are for sure still for humans. The structured format ensures things are readable and testable. Ours also enables a generative UI, which for now at least is still a much faster way to make visual edits while working with an AI, vs always through it.
  - mollifier14 13d ago
    I think we're still ways out until companies will blindly trust AI that the data they pulled is correct. If a data team member sees a dashboard or chart, their first questions is "Is the SQL below this chart correct?". The easier it is to see the SQL that pulled the data, the better.
    - thingsilearned 13d ago
      Exactly and that's why dbt Charts is a spec in YAML vs a python library. It ensures that the logic stays in SQL where its easy to test and trace.
mirelahmd 13d ago
thats intresting
dgudkov 13d ago
It's neat but pretends to be more innovative than it actually is. BI has already been decoupled from everything else. People use AI to generate Excel and Power BI reports. YAML/XML/JSON - that doesn't matter. AI can generate whatever you instruct it to do. So yes, a nice and logical development of dbt, but hardly as innovative as the blog post wants to sound. Nevertheless, I think it's a good idea that will be popular in certain circles. Hiring a professional data designer is a good idea - data visualization is very easy to get wrong.
- mollifier14 13d ago
  AI can definitely generate whatever you tell it to do, but what to do with that artifact afterwards? If you want it to be reusable it needs to be a well-defined structured protocol/language. What good is a YAML describing a chart if all I can do is to give it back to the agent and say "read this and create a chart from it", the result will be vastly different from the chart you got the first time.
  - dgudkov 13d ago
    > the result will be vastly different from the chart you got the first time. AI can generate reusable artifacts including definitions of the data sources, why not? Most BI dashboards are just XML or JSON (or YAML) files and include definitions of data sources (directly or via semantic models). I struggle to see how dbtCharts is different. Yes, your YAML schema is clean and nice, but that's because you're in the early stages :) Once you go through feature bloat, your YAML format will become much more complex. AI can generate an XML/JSON/YAML definition of a BI report according to a spec and link the data source in whatever form it should be referenced in the file. For instance, here is a skills file for defining data sources (semantic models) in AI-generated Power BI dashboards: https://github.com/microsoft/skills-for-fabric/blob/main/plugins/powerbi-authoring/skills/semantic-model-authoring/SKILL.md https://github.com/microsoft/skills-for-fabric/blob/main/plu...
- oconnore 13d ago
  I think I agree, but I'm not sure where Dave is claiming this is a paradigm shift in data visualization? One of the key claims is actually that it's based on _old_ established visualization patterns from before BI tools were popular, and therefore results in consistently nice charts. The other key claim is just that it's simple and maintainable. Sometimes tools & products can be useful as just well executed points in the known design space. You can already do all this with AI, but it's perhaps a little bit less nice and less maintainable. [I work at dbt/Fivetran]
engrav3er40 13d ago
This looks really slick! I was building something similar, so visuals are re-useable artifacts that external services know how to render, where we ask agents in whatever the interface is, slack, team's other agentic harnesses etc. and the agents receive the spec from the service, in this case dbt charts. if there was a unified spec that was agreed upon these third-party harnesses and apps would all speak the same charting language which would be super cool. I haven't read through it in detail but how does this differ from something like https://github.com/vega/vega-lite https://github.com/vega/vega-lite
- mollifier14 13d ago
  We actually use vega-lite under the hood. vega-lite is vast tool set to build charts with static data. dbt Charts adds a whole layer on top of that, which is dashboards with repeatable SQL queries. Also dbt Charts comes with a lot of opinionated chart style ideas. So vega-lite is a toolbox for chart assembly, and we use that toolbox to build dashboards. On the standardized charting language, that would be the dream. All agents giving the same spec when they want to build a chart or dashboard, and then having different renderers of that. That is a steep goal. Such a language would need to be simple but still extremely versatile. I'm not sure that combination exists yet. Our language is simple and fairly versatile, but not as versatile as vega-lite itself, or JavaScript code even. Maybe we can evolve in that direction though
  - engrav3er40 13d ago
    https://openai.com/index/put-data-to-work/ https://openai.com/index/put-data-to-work/ was a compelling demo for me, being able to interact with a artifact and contextually EDA on a series or outliers is lowering the barrier to entry for BI exploration. I think meeting engineers where they work and being flexible and open sourcing these capabilities is really great to see
  - crabmusket 13d ago
    What do you think about GGSQL, or is that not entirely aligned with what you want? They also produce vega-lite JSON as output. https://ggsql.org/ https://ggsql.org/
theodorewiles 13d ago
how does this compare w/ evidence (https://evidence.dev/ https://evidence.dev/)?
- kantselovich 13d ago
  All docs for evidence.dev are AI-hallucinated …YMMV
  - hughess 13d ago
    Hi, I'm one of the founders of Evidence. We're in the process of overhauling our docs and I'd love to hear any issues you ran into so we can make them better. Any feedback appreciated!
deleted 13d ago
[deleted]
carterschonwald 13d ago
repeat after me: yaml is not a programming language. (boo, hn strips emojis, i should know that) very disappointed that their domain specific language is just yaml. conditionals and variable binding become insane war crimes when yaml comes to town. you have a friggin llm, do better and when we computer folks see the word language its implied that its a computing on computers language not a friggin data format. edit: the yaml to avoid complexity that should live in the sql side can back fire, some folks I was working with last fall were evaluating if a yaml based OLAP tool would work for them, and there were some pretty gnarly gotchas from a yaml based approach. Secondarily, theres a real case to be made that having the data linkages not visible in the charting layer means that groups of related plots with different axes wont have the right data linkage without forcing a lot more ETL for what should be a quick plot if the data already fits in memory.
- Evidlo 13d ago
  what would you have chosen for your DSL? Ideally something not from scratch
  - carterschonwald 13d ago
    i'm not sure if that caveat is sensible :) theres actually a very important reason you want it to be an actual embedded dsl or tiny programming language! The reason why llms can code at all is the hugeeeee amount of RL based on the loop of 1 "write code", 2 get compile time or runtime errors,3 fix it and iterate. Data file formats dont have that feedback loop so models will fall off the rails faster. Writing code that fits a latent adhoc schema just wont work as well, or will require burning a lot more context. from that perspective, it could just be an EDSL little library in the host language, or it could be a friggin little custom language with an interpreter and good error messages.
    - thingsilearned 13d ago
      Oh to be clear > dct validate <file.yml> Or any of the other commands that read the file will quickly fail with any syntax or SQL issues. It’s not just an open schema.
helloitsmet00 13d ago
How is this distinct from something like Mosaic (https://idl.uw.edu/mosaic/spec/ https://idl.uw.edu/mosaic/spec/)?
rgbrgb 13d ago
very cool! i'd been thinking about this idea and found vega-lite to be an interesting take as well [0]. i'll compare and look at folding this into setoku for app generation [1]. right now apps are just html blobs your claude authors + a mechanism for populating them with live data. definitely hard to audit but very flexible for operators to claude together internal apps. anyway, the charts look decent but really depend on the model that's making them and don't really follow any sort of style guide (example: https://demo.setoku.com/apps/a7a1240ae0bc202c5eefa1cc https://demo.setoku.com/apps/a7a1240ae0bc202c5eefa1cc). Your lib could bring some consistency and make global styling possible. [0]: https://vega.github.io/vega-lite/ https://vega.github.io/vega-lite/ [1]: https://setoku.com https://setoku.com
bbkane 13d ago
Interesting, but I'm not sure how it's different from Observable Framework ( https://observablehq.github.io/framework/ https://observablehq.github.io/framework/ ) for dashboards as code. I like that one because it's Markdown and JS instead of a language defined in YAML + templates
- jerdthenerd 13d ago
  The use case that immediately came to mind for me was to use dbt charts as a rendering method for an MCP App. You don't really want to give a LLM client code execution environment like Observable Framework does. dbt charts appear to validate the entire yaml input including the SQL being sent to the data source. So I'm getting: a data vis layer that can be dynamically defined and rendered via LLM/MCP client without the headache of sandboxing a JS Runtime environment.
- kantselovich 13d ago
  I like the observable framework too - very flexible, you can nail very specific visualization details by dropping down to JS/html. Maybe this is targeted to pure SQL folks that can get lost in UI details. PS: one issue that I have with observable framework is authentication and authorization , it requires some system to be built on top of it to handle authn.
zahlman 13d ago
Let's say (because it's true) I've been programming for close to 40 years but in completely different domains, such that the concept of "dashboard" means almost nothing to me. Could someone explain what this project actually is, or what "BI" is or why I would want it? I mean, I assume that "BI" is the thing that "PowerBI" implements, but other than that I couldn't tell you anything.
- bryanrasmussen 13d ago
  well BI is I believe business intelligence, which is sort of like military intelligence, the set of practices and tools that have evolved around the need to present data to business people in such a way that they can make sensible decisions regarding their business. on edit: So a dashboard is just one of those things were you see all the things you can do or interact with assembled together and from which you can navigate into any particular tool or view of data. Probably there would be meaningful data views on top. Like Number of Purchases versus people who started a purchase. And you could then drill down into the data that this chart represented to see how long purchases took, repeat customers, when people leave process or purchase etc. etc. The dashboard is the entry point for how you will navigate your business data.
  - zahlman 13d ago
    So they're trying to simplify what, the addition of new views to the dashboard?
    - data_ders 13d ago
      (Anders here, on the dbt Charts team) What drew me to the dbt project back in 2020 and what ultimately led me get a job at dbt Labs was this notion that when compared to software engineering teams, analytics teams had been vastly unserved by their tools. In 2016 (and largely to this day), BI teams work in point-and-click interfaces without Software Development Lifecycle mainstays like source control, testing, and deployment environments. There are BI engineers who do work like software engineers, but the gap b/w those who work like SWEs and those who don't is wide. dbt Charts (like dbt before it did for data engineers) aims to empower data analysts to work with stakeholders in a more efficient and sustainable manner than was previously possible. The means to this end are: a succinct YAML DSL spec for defining charts, a powerful CLI that lets you validate, compile, and render the code into a dashboard spec the YAML. Like data analysts being able to do PRs for changes to a dashboard is still rather unheard of especially if those PRs are in repos with other analytics code. Many BI vendors do ship some form of diffing and environment promotion, but virtually always these features fall short of what SWEs use every day.
RobGoretsky 13d ago
Congrats on the launch! As someone who as led BI teams for many years, this looks great.. but - and you know this too, I’m sure - visualizations are only a small piece of the BI tool value prop. There’s governance, access controls, interactivity, and connectivity to semantic layers. The examples here show raw SQL but in reality we’d want something more abstract - names of dimensions and measures would probably be part of it. So, are those other pieces going to be part of dbtTran Cloud?
- thingsilearned 13d ago
  Yup! Big plans for deep semantic layer interaction
- data_ders 13d ago
  hey -- Anders here, I've been helping the dbt Charts team. I loved this list you've enumerated here > There’s governance, access controls, interactivity, and connectivity to semantic layers I'd add to that list as well: KPIs, dropdowns, text boxes, theming, shared data sources. If you're familiar with Vega-Lite [1], I like to explain dbt Charts as the Vega-Lite but for BI, in that it is a language that specifies all of the components of BI. > are those other pieces going to be part of dbtTran Cloud? Certainly there are some features that are more conducive to being offered as a managed service. However, we've built this enterprise BI tool backwards in that we've started less with commercialization in mind, but rather laying the groundwork in the language and OSS project, so that we need not reinvent the wheel over and over again. I'm hand-waving here about a future that doens't yet exist. But in theory dbt Charts could be extended in the front end to allow for not just SQL or SL metric support, but any query language. Same for the backend, we dbt Charts can render to png and html today, but other formats are also possible! [1]: https://vega.github.io/vega-lite/ https://vega.github.io/vega-lite/
  - kjnesbit 12d ago
    [dead]
mrtimo 13d ago
Malloy is an alternative to dbt, they have a similar product called Malloyyo [1], and Publisher [3], you can also the chat with HN data demo they have [4]. DBTCharts says you can serve charts locally, but it seems they want you to use their hosting service in production. Whereas, Malloyyo / Publisher are free to use anywhere. If you like college football checkout how I visualize drive data in [2], made with Malloyyo. [1] - https://github.com/malloydata/malloyyo https://github.com/malloydata/malloyyo [2] - https://mrtimo.github.io/cfb-games/games-2026.html?%24SEASON=2026&%24DIVISION=fbs&%24CONFERENCE=Big+Ten&%24GAME_WEEK=Week+2&%7Esort=thrill https://mrtimo.github.io/cfb-games/games-2026.html?%24SEASON... [3] - https://github.com/malloydata/publisher https://github.com/malloydata/publisher [4] - https://community.credibledata.com/hackernews https://community.credibledata.com/hackernews
- kjnesbit 12d ago
  Worth separating the layers though, because "alternative to dbt" undersells what Malloy is for. dbt transforms and materializes tables. Malloy describes what the tables mean -- dimensions, measures, join paths, who's allowed to see what -- and compiles that down to SQL. It sits on top of dbt models fine, and plenty of people run it exactly that way. Publisher runs the model: you define the what, the engine figures out how. You write down what counts as a sale, how revenue is calculated, who sees which rows. Reshaping the data out of the form your systems store it in, deciding what to precompute, serving whichever agent or dashboard or API is asking -- that's the Publisher's job. A chart spec has to get its numbers from somewhere. If "revenue" is defined inline in the chart's SQL, the definition problem moved, it didn't get solved. Define it once in a model and the chart just renders it. Engineering detail if anyone wants it: https://www.credibledata.com/blog/posts/inside-the-ai-analytics-engine https://www.credibledata.com/blog/posts/inside-the-ai-analyt...
karakanb 13d ago
Hi there, Burak here, creator of DaC and Bruin: https://github.com/bruin-data/dac https://github.com/bruin-data/dac This is obviously a space we are very much interested in, so it is definitely nice to see approaches that attack the same problem. I haven't played with dbtcharts in depth yet but it looks very similar to DaC in principle, and also in the actual spec. I believe the industry definitely needs solutions like this to help get out of the legacy BI tools as Bİ is one of the biggest bottlenecks for AI adoption in large orgs. Excited to see further competition in the space, nice launch!
jp_monteiro 13d ago
dbt/Fivetran announces that they will unbundle BI by bundling it with their ELT solution. Ironic to say the least.
verdverm 13d ago
Man, I didn't think anyone would out yaml helm, but here we are not just templating invisibly scoped files (yaml), but also SQL within them? Looking forward to the yaml confusion when helm/dbt both see their default "charts/" directory in the same repo, or the dbt chart is set as a config map so it can be updated without rolling a new version of the full app... helm_argo is already a nightmare rant aside, this does look super useful, and I do have CUE to help with the yamhell, but I may still prefer js/ts options so I can dynamically change the chart (like user clicking a dropdown for a different set of data). Sounds cool until the "dynamic" part of the chart shows it's limitations in crafting your ideal UX I'll definitely be taking this for a spin, gets at that unbundling and "I need a quick chart" situations
- mollifier14 13d ago
  I don't quite understand the YAML hate from some people. I agree that Helm is messy, but it has a lot of coding like things in YAML and then it feel like dependencies just live randomly somewhere. For the most part our YAML files are self contained. Yes you can use ref() and also pull other files, but most of that is obvious in syntax. What we should do is to make sure our YAML is as easy to navigate as possible in various editors, especially VScode with the extension
  - verdverm 12d ago
    Or just use CUE, it's sooo much better, you can use it in conjunction with/extension to all the popular formats, get real schemas/imports/modules I discovered CUE after trying to do too much in yaml, after adding imports I had to step back and ask what I am I doing. It's super hacky, a real language is much better long-term in reliability and maintainability. DevOps seems to enjoy the pain, unsure why we continue to use messy tools. CUE is actually nice and fun to use before any comparisions to existing config formats.
hackandthink 13d ago
You can specify Apache Superset Dashboards, Charts, ... using yaml, for example: https://github.com/preset-io/headless-bi-blog-post-examples/blob/main/dashboards/Demo_dashboard.yaml https://github.com/preset-io/headless-bi-blog-post-examples/... But this is mostly just a dump of internal Superset data structures.
- gps372 13d ago
  Superset comes with a built-in MCP server now https://superset.apache.org/admin-docs/configuration/mcp-server/ https://superset.apache.org/admin-docs/configuration/mcp-ser..., which you need to expose as another container. Any agent with proper authentication (JWT mostly) will be able to create and manage dashboards via natural language.
chupchap 13d ago
Okay nice chart, but can I click in and filter into the data? Visualisations are not what a BI tool does; it's just the tip of the iceberg.
- mollifier14 13d ago
  Yes you can! Chart can have links assigned, either automatically or dynamically. Those links can either take you to drill down pages with the data listed out, or it can dynamically change filter/variable values and change the data displayed on the whole dashboard. See https://docs.dbtcharts.com/boards/linking/?h=links https://docs.dbtcharts.com/boards/linking/?h=links
rcarmo 13d ago
Neat, but… I’ve built up skills for my agents to just generate SVG charts and embed them in the chat timelines. A library helps, sure, but you can get surprisingly good results that cover 80% of the timeline and bar chart visualizations without any libraries, and that goes for diagrams as well (mine generate .drawio XML)
kelvo_ran 13d ago
[dead]
tbolive 13d ago
There is also an interesting approach recently published: VACP: Visual Analytics Context Protocol https://vacp.dev/ https://vacp.dev/
utopiah 13d ago
I'm an idiot really... based on the title I though it was a chart solution to establish a discussion, with... actual people. I was starting to imagine a shared pointer, a way to interact with a notebook, a la Observable, with the data and a staging environment for each participant, etc. Nope, it's about agents. Gosh I'm so "behind" it's painful. /s
marcy_74 13d ago
This looks super practical for sharing quick daily metrics in Slack or Teams. Saves a lot of context switching for simple updates.
pgt 13d ago
This is great, but why did it have to be YAML?
ahmedkhafsi 13d ago
This is actually pretty good. I love the unbundling premise, this is exactly where we are heading. I might use this as a good format for reports in a tool I developed. Thanks for sharing.
mritchie712 13d ago
This is cool, but I think too late. People are already used to getting *exactly* what they want from an agent. e.g. in our agent (https://www.definite.app/ https://www.definite.app/) we often see people take pictures of a sketch on a piece of paper or a screenshot from a few other tools (Stripe + Excel). Our agent has templates to start from, but ultimately writes a react app to give the user what they want. It'd be hard to get that experience in a framework like this.
Mugshelf 13d ago
Seen this come up a lot internally. Quick charts in Slack are super useful for daily KPIs, avoiding opening BI tools.
anentropic 13d ago
This looks good... probably nice to have integrated with dbt like this. I have to dig in a bit more to what is possible in https://docs.dbtcharts.com/charts/extensibility/ https://docs.dbtcharts.com/charts/extensibility/ and https://docs.dbtcharts.com/charts/interactions/ https://docs.dbtcharts.com/charts/interactions/ so far, and how feasible it is to actually use the end result in a customised website. Also similar: https://github.com/microsoft/flint-chart https://github.com/microsoft/flint-chart This is also likely to compete with features already provided by the warehouse such as https://docs.databricks.com/aws/en/dashboards/manage/visualizations/ https://docs.databricks.com/aws/en/dashboards/manage/visuali...
iamacyborg 13d ago
Google really shit the bed with Looker and LookML huh.
ipkstef 12d ago
im dumb. can someone explain why this is better than just telling your llm to build a chart with something thats been around for over a decade like chart.js or anything else that we built to solve for displaying charting?
timow 11d ago
Analytics is becoming wildly more useful now that we can ask any question in natural language to visualize big data sets. Amplitude has been doing some excellent work in this area, massive unlock for me as a founder. Dave built Chart.io and been seeing how much they’ve poured into this from his decade of experience for gnarly data.
bitmetric 9d ago
[flagged]

295 points by thingsilearned 13d ago

Hi HN, I'm Dave the founder of Chartio (YC'10 now Atlassian Analytics), announcing today dbt Charts, an open source YAML dialect and tool for declaring and rendering dashboards. When making dashboards with claude or other agents, a lot of free-form artifacts are created that makes it hard to audit and scale. dbt Charts is a simple YAML dialect that declares and renders a chart (think markdown but for dashboards). Along with dbt its Apache 2.0 and launched today. We hope this language + AI help make the BI space more open with dashboards as concise auditable code. Would love any thoughts and feedback.

mceoin 13d ago
Congrats on the launch Dave! I was wondering who was going to launch an attempt at industry standard here. Hope it gains widespread adoption.
- thingsilearned 13d ago
  Thank you Eoin!
iamcreasy 13d ago
Thank looks cool. Do you guys have plan to add interactivity to these charts? Will it be possible to inject JS in these charts?
- thingsilearned 12d ago
  re: interactivity We already have variables and links (which work with variables)[1]. Variables create interactive menus that update urls, queries and charts. If you have a variable `region` and you set it the url will add a get param ?region=<value> Each chart also has a basic `link:` property can use to link to the existing or other urls with the variables set. For example type: bar x: revenue y: region link: '?region={{ region }}' The result is a big range of flexibility, for example [2] here's an example of Conways Game of Life inside of dbt Charts. [1] variables example - https://play.dbtcharts.com/?example=variables%2Fall-input-types.yml https://play.dbtcharts.com/?example=variables%2Fall-input-ty.... [2] Conways game of life - https://play.dbtcharts.com/?example=variables%2Fgame-of-life.yml https://play.dbtcharts.com/?example=variables%2Fgame-of-life...

fletchrichman 13d ago

This looks great can’t wait to try it out

marojejian 13d ago

Nice to see something built for AI that's supporting both openness and interpretablilty.

mollifier14 13d ago

A beacon of hope between all the vibe coded JS slop charts and dashboards! I love that this creates artifacts that are readable, maintainable and reproduce the same dashboard consistently (deterministically!), just with fresh data.

thingsilearned 13d ago
Yup, that's exactly the idea.

nzoschke 13d ago

This looks great. "Unbundling BI" is absolutely where things are headed now that more people have agents, coding agents, agent computers to help with work. I'm seeing this all up and down knowledge work tools. I've started treating email as a BI problem -- ETL it from Gmail and and create many different views into it and reports from it. I just wrote up some thoughts on that here: https://housecat.com/blog/making-gmail-data-fast-for-humans-and-agents https://housecat.com/blog/making-gmail-data-fast-for-humans-... A natural followup is how to better visualize this data in chat. The DBT table component looks like it could help https://docs.dbtcharts.com/charts/tables/ https://docs.dbtcharts.com/charts/tables/

nzoschke 13d ago
Wow https://github.com/dbt-labs/dbt-charts https://github.com/dbt-labs/dbt-charts has a great chat user / agent coding experience: > Make charts of this with dbt Charts. Start with: uv tool install dbt-charts && dct skills intro > > build a dashboard of my hiring inboxes: list of candidate name / email / locale, application quality, response age The one-shot dashboard is surprisingly good.
stackghost 13d ago
>This looks great. >"Unbundling BI" is absolutely where things are headed now that more people have agents, coding agents, agent computers to help with work. Agreed. Coupled with bento[0] for slide decks, I think this type of project is a very welcome development, helping us move away from walled gardens and proprietary software suites. [0] https://github.com/nyblnet/bento https://github.com/nyblnet/bento
- nzoschke 13d ago
  Thanks for sharing this too. It reminds me of GistDeck a super old project that turned a gist into slides. Infinitely better than powerpoint or GSlides. https://github.com/nzoschke/gistdeck https://github.com/nzoschke/gistdeck
pizzafeelsright 13d ago
Why visualize data? Graphs and charts always felt like the "show your work" in math class. It is forced synesthesia. The rocket either lands or doesn't, safely, as expected. Green and Red lights are abstracted data plots. The context should be the focus. "Rocket must land at less than 0.2/mps" and pump the data into that context filter, more - reduce velocity, less - green light.

xnx 13d ago

Is this associated with dbtlabs?

georgewfraser 13d ago
Yes this is a dbt product - will be in the dbt cli soon, we shipped it initially as a separate tool while it’s in preview.

ramesh31 13d ago

Everyone wants to come up with a clever One Spec to Rule Them All for generative UI. My bet is that the bitter lesson still bites. Models will continue getting faster and more error free at single-shot writing things from scratch with primitive libraries, and the flexibility that allows will make all of this for naught.

thingsilearned 13d ago
So this is a fairly domain specific (dashboards) spec and we intentionally avoid getting too generic. The raw HTML/SVG or base libraries approach may well win out, but it does make it quite hard or impossible for humans to follow along and verify for instance where the numbers on a chart came from. I think in a future where AI's doing all that verifying (or we just trust it), the AI might still prefer to use a DSL like ours because the abstraction maintains consistency, lowers maintenance, and saves a lot of tokens. But the most helpful bits of a structured DSL are for sure still for humans. The structured format ensures things are readable and testable. Ours also enables a generative UI, which for now at least is still a much faster way to make visual edits while working with an AI, vs always through it.
- mollifier14 13d ago
  I think we're still ways out until companies will blindly trust AI that the data they pulled is correct. If a data team member sees a dashboard or chart, their first questions is "Is the SQL below this chart correct?". The easier it is to see the SQL that pulled the data, the better.
  - thingsilearned 13d ago
    Exactly and that's why dbt Charts is a spec in YAML vs a python library. It ensures that the logic stays in SQL where its easy to test and trace.

mirelahmd 13d ago

thats intresting

dgudkov 13d ago

It's neat but pretends to be more innovative than it actually is. BI has already been decoupled from everything else. People use AI to generate Excel and Power BI reports. YAML/XML/JSON - that doesn't matter. AI can generate whatever you instruct it to do. So yes, a nice and logical development of dbt, but hardly as innovative as the blog post wants to sound. Nevertheless, I think it's a good idea that will be popular in certain circles. Hiring a professional data designer is a good idea - data visualization is very easy to get wrong.

mollifier14 13d ago
AI can definitely generate whatever you tell it to do, but what to do with that artifact afterwards? If you want it to be reusable it needs to be a well-defined structured protocol/language. What good is a YAML describing a chart if all I can do is to give it back to the agent and say "read this and create a chart from it", the result will be vastly different from the chart you got the first time.
- dgudkov 13d ago
  > the result will be vastly different from the chart you got the first time. AI can generate reusable artifacts including definitions of the data sources, why not? Most BI dashboards are just XML or JSON (or YAML) files and include definitions of data sources (directly or via semantic models). I struggle to see how dbtCharts is different. Yes, your YAML schema is clean and nice, but that's because you're in the early stages :) Once you go through feature bloat, your YAML format will become much more complex. AI can generate an XML/JSON/YAML definition of a BI report according to a spec and link the data source in whatever form it should be referenced in the file. For instance, here is a skills file for defining data sources (semantic models) in AI-generated Power BI dashboards: https://github.com/microsoft/skills-for-fabric/blob/main/plugins/powerbi-authoring/skills/semantic-model-authoring/SKILL.md https://github.com/microsoft/skills-for-fabric/blob/main/plu...
oconnore 13d ago
I think I agree, but I'm not sure where Dave is claiming this is a paradigm shift in data visualization? One of the key claims is actually that it's based on _old_ established visualization patterns from before BI tools were popular, and therefore results in consistently nice charts. The other key claim is just that it's simple and maintainable. Sometimes tools & products can be useful as just well executed points in the known design space. You can already do all this with AI, but it's perhaps a little bit less nice and less maintainable. [I work at dbt/Fivetran]

engrav3er40 13d ago

This looks really slick! I was building something similar, so visuals are re-useable artifacts that external services know how to render, where we ask agents in whatever the interface is, slack, team's other agentic harnesses etc. and the agents receive the spec from the service, in this case dbt charts. if there was a unified spec that was agreed upon these third-party harnesses and apps would all speak the same charting language which would be super cool. I haven't read through it in detail but how does this differ from something like https://github.com/vega/vega-lite https://github.com/vega/vega-lite

mollifier14 13d ago
We actually use vega-lite under the hood. vega-lite is vast tool set to build charts with static data. dbt Charts adds a whole layer on top of that, which is dashboards with repeatable SQL queries. Also dbt Charts comes with a lot of opinionated chart style ideas. So vega-lite is a toolbox for chart assembly, and we use that toolbox to build dashboards. On the standardized charting language, that would be the dream. All agents giving the same spec when they want to build a chart or dashboard, and then having different renderers of that. That is a steep goal. Such a language would need to be simple but still extremely versatile. I'm not sure that combination exists yet. Our language is simple and fairly versatile, but not as versatile as vega-lite itself, or JavaScript code even. Maybe we can evolve in that direction though
- engrav3er40 13d ago
  https://openai.com/index/put-data-to-work/ https://openai.com/index/put-data-to-work/ was a compelling demo for me, being able to interact with a artifact and contextually EDA on a series or outliers is lowering the barrier to entry for BI exploration. I think meeting engineers where they work and being flexible and open sourcing these capabilities is really great to see
- crabmusket 13d ago
  What do you think about GGSQL, or is that not entirely aligned with what you want? They also produce vega-lite JSON as output. https://ggsql.org/ https://ggsql.org/

theodorewiles 13d ago

how does this compare w/ evidence (https://evidence.dev/ https://evidence.dev/)?

kantselovich 13d ago
All docs for evidence.dev are AI-hallucinated …YMMV
- hughess 13d ago
  Hi, I'm one of the founders of Evidence. We're in the process of overhauling our docs and I'd love to hear any issues you ran into so we can make them better. Any feedback appreciated!

deleted 13d ago

[deleted]

carterschonwald 13d ago

repeat after me: yaml is not a programming language. (boo, hn strips emojis, i should know that) very disappointed that their domain specific language is just yaml. conditionals and variable binding become insane war crimes when yaml comes to town. you have a friggin llm, do better and when we computer folks see the word language its implied that its a computing on computers language not a friggin data format. edit: the yaml to avoid complexity that should live in the sql side can back fire, some folks I was working with last fall were evaluating if a yaml based OLAP tool would work for them, and there were some pretty gnarly gotchas from a yaml based approach. Secondarily, theres a real case to be made that having the data linkages not visible in the charting layer means that groups of related plots with different axes wont have the right data linkage without forcing a lot more ETL for what should be a quick plot if the data already fits in memory.

Evidlo 13d ago
what would you have chosen for your DSL? Ideally something not from scratch
- carterschonwald 13d ago
  i'm not sure if that caveat is sensible :) theres actually a very important reason you want it to be an actual embedded dsl or tiny programming language! The reason why llms can code at all is the hugeeeee amount of RL based on the loop of 1 "write code", 2 get compile time or runtime errors,3 fix it and iterate. Data file formats dont have that feedback loop so models will fall off the rails faster. Writing code that fits a latent adhoc schema just wont work as well, or will require burning a lot more context. from that perspective, it could just be an EDSL little library in the host language, or it could be a friggin little custom language with an interpreter and good error messages.
  - thingsilearned 13d ago
    Oh to be clear > dct validate <file.yml> Or any of the other commands that read the file will quickly fail with any syntax or SQL issues. It’s not just an open schema.

helloitsmet00 13d ago

How is this distinct from something like Mosaic (https://idl.uw.edu/mosaic/spec/ https://idl.uw.edu/mosaic/spec/)?

rgbrgb 13d ago

very cool! i'd been thinking about this idea and found vega-lite to be an interesting take as well [0]. i'll compare and look at folding this into setoku for app generation [1]. right now apps are just html blobs your claude authors + a mechanism for populating them with live data. definitely hard to audit but very flexible for operators to claude together internal apps. anyway, the charts look decent but really depend on the model that's making them and don't really follow any sort of style guide (example: https://demo.setoku.com/apps/a7a1240ae0bc202c5eefa1cc https://demo.setoku.com/apps/a7a1240ae0bc202c5eefa1cc). Your lib could bring some consistency and make global styling possible. [0]: https://vega.github.io/vega-lite/ https://vega.github.io/vega-lite/ [1]: https://setoku.com https://setoku.com

bbkane 13d ago

Interesting, but I'm not sure how it's different from Observable Framework ( https://observablehq.github.io/framework/ https://observablehq.github.io/framework/ ) for dashboards as code. I like that one because it's Markdown and JS instead of a language defined in YAML + templates

jerdthenerd 13d ago
The use case that immediately came to mind for me was to use dbt charts as a rendering method for an MCP App. You don't really want to give a LLM client code execution environment like Observable Framework does. dbt charts appear to validate the entire yaml input including the SQL being sent to the data source. So I'm getting: a data vis layer that can be dynamically defined and rendered via LLM/MCP client without the headache of sandboxing a JS Runtime environment.
kantselovich 13d ago
I like the observable framework too - very flexible, you can nail very specific visualization details by dropping down to JS/html. Maybe this is targeted to pure SQL folks that can get lost in UI details. PS: one issue that I have with observable framework is authentication and authorization , it requires some system to be built on top of it to handle authn.

zahlman 13d ago

Let's say (because it's true) I've been programming for close to 40 years but in completely different domains, such that the concept of "dashboard" means almost nothing to me. Could someone explain what this project actually is, or what "BI" is or why I would want it? I mean, I assume that "BI" is the thing that "PowerBI" implements, but other than that I couldn't tell you anything.

bryanrasmussen 13d ago
well BI is I believe business intelligence, which is sort of like military intelligence, the set of practices and tools that have evolved around the need to present data to business people in such a way that they can make sensible decisions regarding their business. on edit: So a dashboard is just one of those things were you see all the things you can do or interact with assembled together and from which you can navigate into any particular tool or view of data. Probably there would be meaningful data views on top. Like Number of Purchases versus people who started a purchase. And you could then drill down into the data that this chart represented to see how long purchases took, repeat customers, when people leave process or purchase etc. etc. The dashboard is the entry point for how you will navigate your business data.
- zahlman 13d ago
  So they're trying to simplify what, the addition of new views to the dashboard?
  - data_ders 13d ago
    (Anders here, on the dbt Charts team) What drew me to the dbt project back in 2020 and what ultimately led me get a job at dbt Labs was this notion that when compared to software engineering teams, analytics teams had been vastly unserved by their tools. In 2016 (and largely to this day), BI teams work in point-and-click interfaces without Software Development Lifecycle mainstays like source control, testing, and deployment environments. There are BI engineers who do work like software engineers, but the gap b/w those who work like SWEs and those who don't is wide. dbt Charts (like dbt before it did for data engineers) aims to empower data analysts to work with stakeholders in a more efficient and sustainable manner than was previously possible. The means to this end are: a succinct YAML DSL spec for defining charts, a powerful CLI that lets you validate, compile, and render the code into a dashboard spec the YAML. Like data analysts being able to do PRs for changes to a dashboard is still rather unheard of especially if those PRs are in repos with other analytics code. Many BI vendors do ship some form of diffing and environment promotion, but virtually always these features fall short of what SWEs use every day.

RobGoretsky 13d ago

Congrats on the launch! As someone who as led BI teams for many years, this looks great.. but - and you know this too, I’m sure - visualizations are only a small piece of the BI tool value prop. There’s governance, access controls, interactivity, and connectivity to semantic layers. The examples here show raw SQL but in reality we’d want something more abstract - names of dimensions and measures would probably be part of it. So, are those other pieces going to be part of dbtTran Cloud?

thingsilearned 13d ago
Yup! Big plans for deep semantic layer interaction
data_ders 13d ago
hey -- Anders here, I've been helping the dbt Charts team. I loved this list you've enumerated here > There’s governance, access controls, interactivity, and connectivity to semantic layers I'd add to that list as well: KPIs, dropdowns, text boxes, theming, shared data sources. If you're familiar with Vega-Lite [1], I like to explain dbt Charts as the Vega-Lite but for BI, in that it is a language that specifies all of the components of BI. > are those other pieces going to be part of dbtTran Cloud? Certainly there are some features that are more conducive to being offered as a managed service. However, we've built this enterprise BI tool backwards in that we've started less with commercialization in mind, but rather laying the groundwork in the language and OSS project, so that we need not reinvent the wheel over and over again. I'm hand-waving here about a future that doens't yet exist. But in theory dbt Charts could be extended in the front end to allow for not just SQL or SL metric support, but any query language. Same for the backend, we dbt Charts can render to png and html today, but other formats are also possible! [1]: https://vega.github.io/vega-lite/ https://vega.github.io/vega-lite/
- kjnesbit 12d ago
  [dead]

mrtimo 13d ago

Malloy is an alternative to dbt, they have a similar product called Malloyyo [1], and Publisher [3], you can also the chat with HN data demo they have [4]. DBTCharts says you can serve charts locally, but it seems they want you to use their hosting service in production. Whereas, Malloyyo / Publisher are free to use anywhere. If you like college football checkout how I visualize drive data in [2], made with Malloyyo. [1] - https://github.com/malloydata/malloyyo https://github.com/malloydata/malloyyo [2] - https://mrtimo.github.io/cfb-games/games-2026.html?%24SEASON=2026&%24DIVISION=fbs&%24CONFERENCE=Big+Ten&%24GAME_WEEK=Week+2&%7Esort=thrill https://mrtimo.github.io/cfb-games/games-2026.html?%24SEASON... [3] - https://github.com/malloydata/publisher https://github.com/malloydata/publisher [4] - https://community.credibledata.com/hackernews https://community.credibledata.com/hackernews

kjnesbit 12d ago
Worth separating the layers though, because "alternative to dbt" undersells what Malloy is for. dbt transforms and materializes tables. Malloy describes what the tables mean -- dimensions, measures, join paths, who's allowed to see what -- and compiles that down to SQL. It sits on top of dbt models fine, and plenty of people run it exactly that way. Publisher runs the model: you define the what, the engine figures out how. You write down what counts as a sale, how revenue is calculated, who sees which rows. Reshaping the data out of the form your systems store it in, deciding what to precompute, serving whichever agent or dashboard or API is asking -- that's the Publisher's job. A chart spec has to get its numbers from somewhere. If "revenue" is defined inline in the chart's SQL, the definition problem moved, it didn't get solved. Define it once in a model and the chart just renders it. Engineering detail if anyone wants it: https://www.credibledata.com/blog/posts/inside-the-ai-analytics-engine https://www.credibledata.com/blog/posts/inside-the-ai-analyt...

karakanb 13d ago

Hi there, Burak here, creator of DaC and Bruin: https://github.com/bruin-data/dac https://github.com/bruin-data/dac This is obviously a space we are very much interested in, so it is definitely nice to see approaches that attack the same problem. I haven't played with dbtcharts in depth yet but it looks very similar to DaC in principle, and also in the actual spec. I believe the industry definitely needs solutions like this to help get out of the legacy BI tools as Bİ is one of the biggest bottlenecks for AI adoption in large orgs. Excited to see further competition in the space, nice launch!

jp_monteiro 13d ago

dbt/Fivetran announces that they will unbundle BI by bundling it with their ELT solution. Ironic to say the least.

verdverm 13d ago

Man, I didn't think anyone would out yaml helm, but here we are not just templating invisibly scoped files (yaml), but also SQL within them? Looking forward to the yaml confusion when helm/dbt both see their default "charts/" directory in the same repo, or the dbt chart is set as a config map so it can be updated without rolling a new version of the full app... helm_argo is already a nightmare rant aside, this does look super useful, and I do have CUE to help with the yamhell, but I may still prefer js/ts options so I can dynamically change the chart (like user clicking a dropdown for a different set of data). Sounds cool until the "dynamic" part of the chart shows it's limitations in crafting your ideal UX I'll definitely be taking this for a spin, gets at that unbundling and "I need a quick chart" situations

mollifier14 13d ago
I don't quite understand the YAML hate from some people. I agree that Helm is messy, but it has a lot of coding like things in YAML and then it feel like dependencies just live randomly somewhere. For the most part our YAML files are self contained. Yes you can use ref() and also pull other files, but most of that is obvious in syntax. What we should do is to make sure our YAML is as easy to navigate as possible in various editors, especially VScode with the extension
- verdverm 12d ago
  Or just use CUE, it's sooo much better, you can use it in conjunction with/extension to all the popular formats, get real schemas/imports/modules I discovered CUE after trying to do too much in yaml, after adding imports I had to step back and ask what I am I doing. It's super hacky, a real language is much better long-term in reliability and maintainability. DevOps seems to enjoy the pain, unsure why we continue to use messy tools. CUE is actually nice and fun to use before any comparisions to existing config formats.

hackandthink 13d ago

You can specify Apache Superset Dashboards, Charts, ... using yaml, for example: https://github.com/preset-io/headless-bi-blog-post-examples/blob/main/dashboards/Demo_dashboard.yaml https://github.com/preset-io/headless-bi-blog-post-examples/... But this is mostly just a dump of internal Superset data structures.

gps372 13d ago
Superset comes with a built-in MCP server now https://superset.apache.org/admin-docs/configuration/mcp-server/ https://superset.apache.org/admin-docs/configuration/mcp-ser..., which you need to expose as another container. Any agent with proper authentication (JWT mostly) will be able to create and manage dashboards via natural language.

chupchap 13d ago

Okay nice chart, but can I click in and filter into the data? Visualisations are not what a BI tool does; it's just the tip of the iceberg.

mollifier14 13d ago
Yes you can! Chart can have links assigned, either automatically or dynamically. Those links can either take you to drill down pages with the data listed out, or it can dynamically change filter/variable values and change the data displayed on the whole dashboard. See https://docs.dbtcharts.com/boards/linking/?h=links https://docs.dbtcharts.com/boards/linking/?h=links

rcarmo 13d ago

Neat, but… I’ve built up skills for my agents to just generate SVG charts and embed them in the chat timelines. A library helps, sure, but you can get surprisingly good results that cover 80% of the timeline and bar chart visualizations without any libraries, and that goes for diagrams as well (mine generate .drawio XML)

kelvo_ran 13d ago

[dead]

tbolive 13d ago

There is also an interesting approach recently published: VACP: Visual Analytics Context Protocol https://vacp.dev/ https://vacp.dev/

utopiah 13d ago

I'm an idiot really... based on the title I though it was a chart solution to establish a discussion, with... actual people. I was starting to imagine a shared pointer, a way to interact with a notebook, a la Observable, with the data and a staging environment for each participant, etc. Nope, it's about agents. Gosh I'm so "behind" it's painful. /s

marcy_74 13d ago

This looks super practical for sharing quick daily metrics in Slack or Teams. Saves a lot of context switching for simple updates.

pgt 13d ago

This is great, but why did it have to be YAML?

ahmedkhafsi 13d ago

This is actually pretty good. I love the unbundling premise, this is exactly where we are heading. I might use this as a good format for reports in a tool I developed. Thanks for sharing.

mritchie712 13d ago

This is cool, but I think too late. People are already used to getting *exactly* what they want from an agent. e.g. in our agent (https://www.definite.app/ https://www.definite.app/) we often see people take pictures of a sketch on a piece of paper or a screenshot from a few other tools (Stripe + Excel). Our agent has templates to start from, but ultimately writes a react app to give the user what they want. It'd be hard to get that experience in a framework like this.

Mugshelf 13d ago

Seen this come up a lot internally. Quick charts in Slack are super useful for daily KPIs, avoiding opening BI tools.

anentropic 13d ago

This looks good... probably nice to have integrated with dbt like this. I have to dig in a bit more to what is possible in https://docs.dbtcharts.com/charts/extensibility/ https://docs.dbtcharts.com/charts/extensibility/ and https://docs.dbtcharts.com/charts/interactions/ https://docs.dbtcharts.com/charts/interactions/ so far, and how feasible it is to actually use the end result in a customised website. Also similar: https://github.com/microsoft/flint-chart https://github.com/microsoft/flint-chart This is also likely to compete with features already provided by the warehouse such as https://docs.databricks.com/aws/en/dashboards/manage/visualizations/ https://docs.databricks.com/aws/en/dashboards/manage/visuali...

iamacyborg 13d ago

Google really shit the bed with Looker and LookML huh.

ipkstef 12d ago

im dumb. can someone explain why this is better than just telling your llm to build a chart with something thats been around for over a decade like chart.js or anything else that we built to solve for displaying charting?

timow 11d ago

Analytics is becoming wildly more useful now that we can ask any question in natural language to visualize big data sets. Amplitude has been doing some excellent work in this area, massive unlock for me as a founder. Dave built Chart.io and been seeing how much they’ve poured into this from his decade of experience for gnarly data.

bitmetric 9d ago

[flagged]