Hacker News

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

>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

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.

Congrats on the launch Dave! I was wondering who was going to launch an attempt at industry standard here. Hope it gains widespread adoption.

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.

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.

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]

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.

Say you have an inventory - list of cloud database instances from all engineering teams in the org.

Is this list growing over time or shrinking or remains the mostly the same?

If the list is growing, is it growing evenly across all teams , or some teams stand out? Can I narrow down to a few teams and compare?

What about overall health of the inventory - how many instances list security or billing optimization findings, how many instances are on the version that would be out of support soon and would need to be upgraded?

A dashboard can answer all those questions immediately and make issues visible, as opposed to a long list in a form of a spreadsheet.

I'm not going to pretend to be an expert at it, but BI tools let you interrogate your data. This can be used for endless use cases for basically any department in an organization. But for instance, if you're a sales leader you might have some questions about all of the sales and marketing data in your company to focus your team's efforts for the next quarter. When you figure out which questions are actually returning useful findings, you then can take a set of these and build a dashboard which lets you easily re-examine those particular questions and their results with always up-to-date (or up-to-date-ish) data and can easily share it with the team.

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.

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/

Yup! Big plans for deep semantic layer interaction

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

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.

what would you have chosen for your DSL? Ideally something not from scratch

Fair hit on "language". I keep forgetting YAML stands for "YAML Ain't Markup Language". What we built is a declarative spec written in YAML, and that's deliberate. Think of it as HTML for boards rather than a programming language. The tradeoff is readability and structure versus flexibility.

That lack of flexibility is actually a feature for one of the bigger problems we're solving: lineage, or knowing where a number came from. If the chart layer can't transform data, the logic stays in SQL, where you can version, test and audit it.

It's also a choice about who this is for. The data community already works in SQL, Jinja and YAML every day, so there's no new language to learn.

All docs for evidence.dev are AI-hallucinated …YMMV

Yup, that's exactly the idea.

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.