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 [2] - https://mrtimo.github.io/cfb-games/games-2026.html?%24SEASON... [3] - https://github.com/malloydata/publisher [4] - https://community.credibledata.com/hackernews

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.

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-...

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/

Interesting, but I'm not sure how it's different from Observable 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

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). Your lib could bring some consistency and make global styling possible.

[0]: https://vega.github.io/vega-lite/

[1]: https://setoku.com

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.

Hi there, Burak here, creator of DaC and Bruin: 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!

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

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.

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/ and 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

This is also likely to compete with features already provided by the warehouse such as https://docs.databricks.com/aws/en/dashboards/manage/visuali...

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)

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

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

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.

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

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/) 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.

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?

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.

You can specify Apache Superset Dashboards, Charts, ... using yaml, for example:

https://github.com/preset-io/headless-bi-blog-post-examples/...

But this is mostly just a dump of internal Superset data structures.

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.

Is this associated with dbtlabs?

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

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.

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

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.

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

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

undefined

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.

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

This looks great can’t wait to try it out

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

thats intresting

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?

Google really shit the bed with Looker and LookML huh.

[flagged]

[dead]

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