dbt Charts: Better Data Graphics with AI

Ben Jones: I'm Ben Jones, the show host here. Well, this is a pretty amazing episode. I've got a couple of folks joining me: RJ Andrews and Dave Fowler. There they are. Hi, guys. These are the people responsible, along with, I'm sure, a large team, for dbt Charts.

Dave, I've been following his work for many years. He founded Chartio, a data visualization application, and that was acquired. And now he's been brought on board to launch dbt Charts.

RJ Andrews and I go way back. I just had dinner at his home a week or so ago when I was in San Francisco. RJ, wow, I don't even know how to introduce him. He's the author of Info We Trust. He's an artist, he's a historian, he's a kayaker. He's also now a BI tool builder. RJ and I could have chatted for many, many hours. He's a good friend of mine. So welcome to the show, both of you.

Let's start with a simple question. dbt Charts: what is it? Why should listeners of the show want to know more about it? And how does it fit into the bigger picture of what dbt is doing, what Fivetran's doing? Take it away, guys. Give us an overview.

Dave Fowler: Yeah, dbt Charts is an open-source language for making dashboards. Basically, what we've seen in all our customers at dbt, and what the marketplace is asking for, is that self-service is finally here. Codex can make great dashboards, or pretty good dashboards, and people vibe code those. People are using it all the time, connecting it to their BigQuerys or their Snowflakes, their warehouses, and making a bunch of dashboards.

This new world is really exciting, but the tools for it so far are really rough, and you can make a huge mess. It can create tons of different JavaScript or Python and use multiple different charting libraries. Your transformations go in different places, and each dashboard is its own separate application. Where it's hosted is kind of a mess. So it makes this ungovernable world for data teams. And so data teams are understandably very cautious about enabling that inside of companies. And when they do, or it gets out, they're overwhelmed with: can you maintain this? Can you validate that this dashboard's correct? And it's a pile of code that you can't really audit or clean.

So we saw this big opportunity, because that's very similar to what the world of transformation looked like 10 years ago, before dbt. Ten years ago in transformation, there were either big drag-and-drop UI platforms for cleaning your data, or there were Python scripts, one-off things that you would do. And dbt came in and said, there's this great middle layer that's SQL-based. They made this great framework for doing those transformations with the right seam, with the right language, and it really took off and was really popular. It continues to be.

So we're doing the same thing now, but at the charting layer. We really think that the right seam is to take the chart layer out of BI and make this open standard. We think of it as a markdown for dashboards. It's the easiest spec to declare: here's what a dashboard is, here's how I want to see the data. In the same way that SQL is the declarative language for describing what data you want, this is the declarative language around that, which declares how you want to see it.

Having that open source, having it an open standard, having it really easy to read and test against, brings all kinds of benefits. It allows you to have that self-service analytics. If you tell Claude to use dbt Charts instead of Claude dashboards, it will make better dashboards for fewer tokens, and it will back them up into Git, into your dbt repo. We put a charts folder next to your models folder in those dbt repos, so that your modeling and your charts are right next to each other. There are all kinds of benefits to that.

So we see this world as dashboards as code. AI can work with code; that's where we think things are going. But what code is that? Is it just a pile of JavaScript, or is it a really nice spec with a lot of structured options that you can extend and theme and parse and read and test?

RJ Andrews: Yeah, from a narrative storytelling perspective: charts can be used privately, analytically, Tukey-style EDA, where the only consumer is you. That's a totally legitimate and perfect use of charts, and one of the ways I use charts every week. But ultimately, charts are a social technology. It's all about not only sharing some information, but building some shared understanding using information.

And the thing about chatting with AI is that it's completely revelatory for the private user, and nobody ever wants to hear about the chat you just had with an AI agent. It's like trying to tell somebody about your dreams. We don't have the personal context to be interested in hearing about your dreams, and I feel like hearing about an AI chat is similar. So that's why it's amazing to be able to have this self-service experience, but you have to connect it somehow to the social organization, whether that's your company or sharing publicly. And so you need that structure behind it.

Another way I think about this, since Dave talked about structure that's more efficient: technology is really good at giving you grooves, and moving really, really quickly in certain directions. But what grooves are you traveling down? If you have no grooves, then the agent is just vibe coding and making a mess. And if you're in an older tool that isn't built for this age, then maybe you're in the wrong grooves. So thinking about which grooves are right, which grooves you're affording to users, is very, very important.

Ben Jones: So RJ, you got brought on board largely to help define those grooves, right? To bring the historical perspective, the entire arc of the field, into a point of view where you can say, hey, here's a path and a track that agents and humans alike can go on. And this is part of the declarative language that you all are helping to build, right? So give us a perspective on that. What was it like setting out over the past year or so to identify and spec out those grooves? What did you include or not include? How did you go about that task? I think that's a really important story: your overall approach to the challenging question of how we create these pathways for people to follow.

Dave Fowler: This could lead into going one step behind that, to how we got started working together, and even how this project started. Chartio was a big early partner with both dbt and Fivetran, and over the years I really tried to get us to work closely together. When they announced they were merging, I reached out and said, that's fantastic, guys, congrats. If you ever want to go up the stack and make a viz tool on top of your great stack, hit me up. I'll put a dream team together, come out of retirement, and make an awesome product.

I was kind of just saying that on a whim. I never really thought I'd go back into data, to be honest with you. But George responded right away and said, that's exactly what I want to do. So I started making prototypes: what would be interesting to make here? What does AI need to do data really well? I started some of the language, but it was on Vega-Lite, and it was looking like, you know, the past. I was like, man, this looks like BI has looked for the past 15 years.

So I went to RJ and said, you're the best guy at this. I need somebody amazing to make this look like the future, while also bringing in what we've done in the past. RJ has that balance of knowing the history and the design talent for the future.

RJ Andrews: Yeah, there are two design observations I had over the last decade that I think we're only now able to actually implement technically, because of the particular age we're living in. The time is now to do this. If you don't do it now, then somebody else will do something different. You might not have even been able to do this 18 months ago.

Okay, so the first observation. I was teaching in a fishbowl conference room in the World Trade Center. I could see the Statue of Liberty; I was like a million miles in the air. I was doing my bespoke, custom-chart enthusiasm. This was pretty early in my career. And I got cut off mid-sentence: "No, no, no, no. You don't understand. Our CEO will only read a line graph, a bar chart, a pie chart, and maybe you get dots on a map. But that's it. That's all you get."

That was a real turning point, where I shifted my attention, and honestly my interest, away from bespoke contraptions that need all this decoding. I started looking more at basic charts, your column charts or bar charts or line graphs, and how we can make those better. And what I discovered, and I was only able to discover this by being familiar with the history of the craft, because modern statistical charting is only 300 or 350 years old, which honestly isn't that old for a communication technology, is that you can do way more things with bar charts and line graphs than anybody had been doing in the digital space.

What I'm talking about is things like this. We just looked at a chart from the 1930s from Russia, a piece of propaganda, with a horizontal time axis. The first years, 1914, 1915, 1916, are in black. And then from 1917 onward, all the year labels are in red. They're using that to show when the Russian Revolution happens and when red Russia continues.

There's nothing technically marvelous about that. They just changed the color. But it shows you that they're using a piece of a normal chart to be very expressive, to be in tune with the data. And that's a particularly gimmicky metaphor, red Russia, and it doesn't always have to be a gimmick. But what that and thousands of other charts have taught me is that our charts should be working harder for us. And they shouldn't be working harder because there's a brilliant designer who has a stroke of genius. No, charts should be smarter out of the box. There's so much opportunity to make all these small adjustments so that the overall composition not only hangs together better, but is actually more informative.

Ben Jones: Well, what I like about that story about the Russian graphic is that most people, when they're creating a chart, are thinking about the graphical marks themselves: the slices of the pie, the bars, the line segments. But what you described was a designer using an axis as an encoding channel, using the axis itself to convey information. Many other charting tools out there, Excel or Tableau or whatever, might make that particular kind of expression a little more challenging. Whereas what you're describing is a way to open up all of those different elements of the chart to a human or an agent, to express and encode information visually, right?

RJ Andrews: Yeah. And part of it is using these secondary or tertiary surfaces as encoding channels. Another gimmicky flourish: your legend becomes a mini bar chart, stuff like that. So that's one flavor of it. But the more important one is just flipping the structure.

For example, one of the things we were talking about last night at the bar, as we were leaving the office: if you have axis tick labels going up the value axis on the vertical side, and you have four or five of them, but you only have four or five bars on the chart, shouldn't you use that ink to just label every bar directly? Do that by default, instead of having this weird scale and forcing people to figure out how much each bar is? Maybe there's an argument for the other way. But it's about making those structural decisions and having an opinion. And when you have an opinion, not making it the only groove you can be in. Making it very easy for anybody, or any company, to say, "No, actually, this is the way we like it," and have that be their default.

Ben Jones: So RJ, connect the dots from those ideas to dbt Charts. How did some of those insights find their way into what you all built and launched just six weeks ago?

RJ Andrews: The marvelous thing, and the problem, with this new age for people with my personality is that you can finally boil the ocean. One of the first things I did when I joined earlier this year was build something called my design corpus. I'm continuing to build it and add to it, but it basically has every piece of writing I care about from my physical book library: academic papers, essays, scans of old books. It's a phenomenal resource on what's gone before. None of the names in the corpus would be surprising to you.

That's where things start: what are our options? What's the solution space that's possible? Let's look at how this could look. And then bouncing that off our engineer, Christophe, and developing a schema so that things stay organized. Very early on, things kind of went like this in our code base, and now it's just zoom. Everything is very, very smooth and forward moving. You don't want to be looping through everything and having it become a mess. So you're working to provide all this optionality, but in a very clear and clean way.

Ben Jones: I love it. Okay, you talk about what it looks like, so why don't we do that? Let me share my screen, and maybe you all can walk us through what we've got here.

Caveat: this is my first attempt with dbt Charts, and you're looking at it here on the screen. I grew up in Los Angeles, so I'm always fascinated by earthquakes. Basically, a GitHub repo pulls data from the USGS site every hour and writes it to a Supabase database backend. Then I used Claude Code to create this dashboard in the free version of dbt Charts. Granted, I made some adjustments to it in the chat history. What you're seeing is the Viridis palette I requested, the pie chart it actually didn't give me at the beginning, some changes in the styling of the KPI boxes, et cetera.

Guys, could you give us an overview of what we're seeing here and point out the most important elements that you think differentiate dbt Charts? After that, we can get into the story of the fact that there's a free version. But what are we seeing here, and what can people do with this kind of a tool?

Dave Fowler: A big, huge difference is that last tab you were just on: it's all powered by this YAML. So it's language first. We do have more and more BI functionality, UI and permissions, built into the hosted version. So we have a paid, hosted version, but it's all built from this language first.

I've built BI products before, and everything out there is UI first. That's how you had to make these things in the past. But now we've built this to be a language-first BI tool, and it really changes everything. It makes our development much faster and more declarative. It also gives the agent and the CLI full power, because your dashboard is defined in this code and everything works off that. It gives the agent full access to change anything you want, and that's really powerful.

You're showing there that you can go back in history. That came for free, because it's on top of GitHub, so you can revert to your old version just fine. And in our hosted platform, we're adding more and more UI elements. If you go to that first design palette tab and click on a chart, it'll show you what design options are available for that chart. Like Figma or PowerPoint or Power BI and other BI platforms, all the options the language has available, all the various settings, are there for you in drag-and-drop and these forms. As we add new elements, these UI forms are generated automatically.

Claude talks about the things AI creates as artifacts, and I like to call this the Chartifact. It's a chart artifact. It's just a YAML file and it renders, but you have full control. You can click on titles and edit them in place. You can click on text and add text. So we really think about how humans and AI work together, and they work together really well with a UI built on top of a language. I call it making a BI tool backwards: exporting as some language or JSON is the start. It's been a really fun and powerful way to build it.

Going back to how we iterate on these and how we add things: in our spec, we have rules on our code. Our code base has no set defaults in the actual code. It all starts with one template file, and you can inherit and add more, and they all extend each other. So all the settings, like the default format for strings, for currency, what to do about the y max, where the legends should go, all the color counts, are all in this style theme that you extend.

And there's this continuous cycle. RJ looks at a bunch of dashboards and finds what we're missing or what's wrong, and he looks at all this historic stuff, like, here are some really inspiring charts that have done this in the past. And we say, let's add that. We add it as another style theme in the language, and it all propagates from that. That continuous cycle is really fun.

Yesterday we were talking about an example there: if that outlier bar went really high, how do we show that, so that you can still see the rest of the bars and it doesn't shrink the whole chart? We're actually going to make it bust out of the chart. We're playing with a bunch of different designs on that, and it's really fun to iterate on those. RJ found all these old historic examples. Some people twirl the bar, some people bend the bar or break the bar. There are all kinds of different things, from the bespoke world where they were printing one chart at a time, manually.

RJ Andrews: Yeah, the thing about analog versus digital is that digital helps you do more, faster, but only in those grooves, right? Whereas in analog, there's little cost to doing things differently, so you have a lot more design freedom. So when you look at analogs, at how people solved this in the past, it's not that there's a different way of doing it. It's that there are seven different ways of doing it, and five of them are crazy. But usually there's something you can learn from: oh, that's interesting, maybe that should be an option, or maybe that should be the way we just do it.

Ben Jones: Yeah, and wouldn't it be great if we could retain a world where we can do great work digitally, fast, but still have the opportunity to break all the rules? To retain that human spirit of the bespoke graphics you're bringing to the conversation, RJ, like the bar that breaks through the axis in a cartoonish way that's playful and fun and interesting, and in some ways also human. You mentioned this connection of humans and AI and data, which is the whole theme of this show: figuring out how to get the best of all three worlds.

RJ Andrews: And I think that's the difference between what I did before working on dbt Charts and what I'm doing now. Before, I could make a chart where the bar breaks through, and I'd give it all the consideration of what it looked like. Now it's not just what it looks like, which of course we have to figure out. We also have to figure out: when do we allow people to do this? Is it ever a default? Do you allow two bars to break through? What if it's a stacked bar, and both pieces of the stack break through? Is there a warning or an error, or further guidance? Is this part of a skill? You're not just designing the individual instance. You're designing a system that works with the rest of the system, and that's the big change.

Ben Jones: Yeah, it's thinking about the meta layer: not a chart, but a system for creating charts. My hat's off to you guys and your whole team for what you've built.

A couple of things to explore together. One is the industry, the space you're in. This picks up on a couple of questions that were submitted to me via LinkedIn before the recording. Elisa Davis wants to know: let's say a warehouse has a viz tool, like Streamlit or Databricks. Now dbt has charts, and of course standalone AI BI tools also have charts. So her question is, what's the use case where you see people wanting to consume visual analytics at the transformation layer? And I'd add: is the strategy going beyond the transformation layer at this point?

Dave Fowler: First, I don't think we've announced the blog post on this yet, but you can now host these dashboards inside of Streamlit. It's really nice, because it keeps all your dashboards together. Sometimes on Snowflake you're launching several different Streamlit apps, several different servers, and they aren't together. So you can get all the benefits of these charts and still host them inside of Streamlit, and it actually makes it a lot cheaper to do that.

So we want to integrate and work with all these people. It's open source. We hope that Anthropic and OpenAI adopt our Chartifact standard. We want it to really be that markdown for dashboards.

Ben Jones: Yeah. So the goal is not to somehow capture all those viz users into dbt, but rather, at this point in time, as RJ mentioned, to create a standard that everyone can adopt and use.

Dave Fowler: And that's what dbt did. Some ridiculous percentage of dbt users are not paying a dime, you know what I mean? It's an open-source big thing, and it's an open-core model. With dbt, a lot of people find big advantages in paying for the hosted dbt platform, which automates and makes a lot of dbt usage easier. In the same way, we have the hosted version, and we hope people find there are lots of benefits to using it. But the open model, we really hope, becomes the default standard that everybody uses.

Ben Jones: I've seen the idea of creating something free that anyone can benefit from work in my own career, specifically with Tableau Public. Of course, that was closed and proprietary, but there was a highly functional free product that anyone could just use. The founders of Tableau said, trust us, this is going to work, let's just put it out there. And everybody could have said, well, no one's going to want to buy it. But there were enough people who would pay for it for a variety of reasons. So it sounds like part of your strategy is just to let people get involved, and as you pointed out, this will spill over into sales for the company in a way that maybe you don't even have to make a business case for. So talk to me about that. What are your aspirations for where this free platform will go, and what people out there will do with it?

Dave Fowler: When I look back at Chartio, by all means it was very successful. It's now called Atlassian Analytics, and it's driving an enormous amount of sales for Atlassian in the enterprise. There are about four or five times as many people working on it now, and development continues. It's really cool to see all its progress.

But when I look back at the business model I had for it, and at what I learned at Atlassian, they have free tiers, like Jira being free for up to five people. That really got early adoption; people felt comfortable using it. Students could just use it. Tableau Public was similar: you could teach a class on it and not have to contact anybody to ask for a bunch of free licenses. I really wish, in hindsight, I'd done that with Chartio and had a free tier, because it doesn't cost that much to maintain and support. I love that business model. It was something that attracted me to dbt, because it's already so open source, open core. And we hope to add a huge value to the world and the community, and to also have supporting tools that make some money on the side.

Ben Jones: Love it. And like I said, I think it's not only a smart strategy and likely to be effective, but also a bit of a breath of fresh air, in a world where everyone's trying to capture...

Dave Fowler: Could I add one thing, on what I think was Elisa's question?

Ben Jones: Elisa. Yeah, Elisa Davis.

Dave Fowler: When you bring the charting layer right next to the transform layer, so literally your charts are now next to your models in dbt, in the same repo, on the same branch, it gives you so much power and freedom in your testing and your deployment process. Right now there are so many teams that say, we really should rename these columns or move this data. There's a lot of tech debt in your models that you don't want to touch, because when you rename a column, now you have to go run down 20 Tableau dashboards, find where those broke, and go fix them.

That disconnect between BI and the transformation layer has always been a big problem. When they're on the same branch in the same repo and you do a rename, it goes and validates all the dashboards and all the queries and checks whether they run. So you fix them in the same exact branch, and it gets deployed at the same exact time. That ends up being really powerful, having those two things together, where you can be confident that when you make a change, it's going to be fixed all the way to the end.

Ben Jones: Well, it sounds like the nuts and bolts of how the models and the charts are connected in the dbt world gets right to one of the other questions that came in on LinkedIn. This is from Aakash Patel: "When a model changes upstream, how fast does a chart built on it show the change?" So maybe Aakash has also felt this pain point you're describing. And then he asks, "Does it say something moved, though? This is the part that decides whether people trust it." Thoughts on that? It sounds like it picks up right where you left off, having these all in the same place, on the same branch in the repo.

Dave Fowler: Yeah, dbt has long had exposures, which, if you get things linked up, can point to which Tableau dashboards, for instance, are going to be impacted when you change a model. And that's nice, because at least you have a list of the 30 dashboards you have to go change. But that problem actually goes away with this, because it's on the same branch, it gets deployed at the exact same time, and it all gets pre-validated before it pushes live. So if you're using an agent, it will see there were errors in the queries because you renamed a column, and it goes and fixes them automatically. Or you can go do it manually yourself if you're still doing that. So it's a really nice part of it.

Ben Jones: So there isn't the time gap, and it doesn't need to point to anything, because it's all happening in the same workflow. All right, I think that's an answer Aakash will probably like.

Gentlemen, I want to thank you so much for your time. Hats off to you both and to the team. Kudos, and thanks for putting something so valuable out there for all of us. Any last thoughts? You put this tool out there six weeks ago, and of course you've got more changes and improvements coming down the road. What should folks look out for? What would you hope folks jump in and try, now that they've read the announcement and listened to this episode?

RJ Andrews: I'm just excited to see more and more of them in the wild. What's most exciting about the last six weeks is seeing people use what you've built and seeing what they do with it: for example, how they choose a different color palette. My obsession is: I looked at your chart and thought, oh, our maps need a little more love. Maps haven't been priority one, but they'll get some more love. We've got to work on our bubble size, for whatever's happening with Ben's map right now.

What I learned after making things publicly for a long time is that you can only get so good going into your cave and making your precious thing by yourself. If you're really, really good, you can go pretty far. But nothing can soar without other people. That's why it's fantastic working with this team. And the meta version is, that's why we need other people making charts, so we can see what they make, learn from them, and help them make better charts.

Ben Jones: Which is what the team is going to be up to, now that you're seeing so many things shared in the wild. Where can someone go to check that out? Can they see a gallery, or dive in, create an account, and get started themselves?

Dave Fowler: Yeah, dbtcharts.com. There's actually a prompt there for Claude, or Codex, or whatever your agent is. You can literally copy and paste that in, and it will onboard you as well as possible. It'll connect your Git, you just have to authenticate, and it will create an account for you. We try to make that as seamless as possible. Even if you have CLIs like Supabase or gcloud, the agent will often just handle connecting your database for you. All those things that are normally really frustrating in setting up a BI tool, we've tested a lot and streamlined.

So go check it out at dbtcharts.com. It's free for up to three people on your team, and we're coming out with pricing shortly for bigger orgs. But we hope this becomes a free, Tableau Public-like community, where people think of it as a GitHub for charts, where you're hosting and putting up really cool viz.

Ben Jones: You've got to get a Viz of the Day going or something like that, right, RJ?

Dave Fowler: We have custom charts now too, which are really cool, giving you full freedom. Those have been really fun, seeing what people are creating.

Ben Jones: Yeah, that was part of the excitement of the Tableau community for so long: seeing what people were creating outside of the box, breaking some rules, and trying new things. Everyone got really inspired. It was a very creative space, and it still is for many people. I'd love to see that happen in this world of code that you all are unlocking for a lot of us.

Dave Fowler: We have someone on the team, Andrew, who's made a bunch of Tableau Public things, and he asked, "Can you guys do the Betty White chart?" And I said, I don't know, let's try. And sure enough, it very quickly made the Betty White chart, and a bunch of other public things. It's really fun to see.

Ben Jones: Okay, so now you're challenging me to go outside the world of my nice, standard BI dashboard. I think I actually asked for that: give me a nice, standard BI dashboard. So I'm going to be thinking beyond that, Dave, about ways to create all kinds of charts that break the rules and do new things. I think that's where we'll see some of that creativity and exploration and innovation. We've got to keep that spirit alive.

So thanks so much, guys. Really appreciate it. Best of luck. Folks who are listening, look for all the links in the comments and in the show notes: places to get started, to dive in, and to check out what other people are doing. Let's keep this community going. Take care, gentlemen, and we'll talk to you soon.

Dave Fowler: Thank you. Bye-bye.