I’ve written before about introducing Metabase at work and how much of a relief it was to stop being the person everyone pinged for a quick data pull. What I didn’t expect is how little decent video content exists about the tool itself. Plenty of marketing pages explaining what BI software is in the abstract. Not much that actually sits someone down and shows them where Metabase earns its keep.
I know the obvious counterpoint: open an AI, ask it anything, done. But that’s not the same as watching someone build a dashboard and seeing exactly which button they clicked and why. So I decided to record a series and fill the gap myself.
Picking a Database That Isn’t Work’s
Using data from my actual job was never an option, for reasons that don’t need spelling out. I went with Chinook instead - the classic sample database that simulates a music store. Customers, invoices, tracks, artists. Enough real business shape to it that a dashboard built on top actually means something, instead of just counting rows for the sake of counting rows.
I run it through the same Postgres container as my Metabase instance, which turned out to have its own small lesson: the import script I found doesn’t respect the target database you pass on the command line, it creates and connects to its own chinook_auto_increment database regardless. Cost me ten minutes of confusion and an empty table before I noticed. Filed under “read the script before trusting the flag.”
Twelve Episodes, Not One
Instead of a single “getting started” video and calling it done, I scoped out a full progression:
- Setup and connecting a database - the unglamorous but necessary first step
- Question builder vs. the SQL editor - and when to reach for which
- Dashboards and filters - turning separate questions into something a team actually uses
- Models as a semantic layer - so non-technical people don’t need to understand the schema
- X-rays - Metabase’s automatic exploration, good for a first look at unfamiliar data
- Alerts and subscriptions - getting numbers pushed to you instead of checking them
- Metabase alongside dbt - for teams where a separate data team owns the transformation layer
- Permissions - row-level restrictions and who gets to see which dashboards exist at all
- Embedding - putting a dashboard inside somebody else’s application
- Actions - writing data back to the database from a dashboard button
- Click behavior - clicking a bar on a chart to drill into the exact filtered view
- Query caching - the difference between a dashboard that loads instantly and one that doesn’t Twelve scripts later, every episode has a beat-by-beat breakdown of what to say and what to click.
The Alerts Episode Derailed Into a Side Project
This is where it gets familiar, if you’ve read the SQLite migration post. I set out to write a script. I ended up writing software.
The problem was specific: an alert episode needs to show what happens when Metabase actually fires a webhook. Waiting live, on camera, for a real threshold to trip is not usable footage. So instead of scripting around that limitation, I spent an afternoon writing a small Node server with no dependencies that receives the webhook and displays it on a page in real time, with a “send test signal” button for when the real condition won’t cooperate on cue.
It’s a genuinely small thing. In-memory storage, capped at two hundred entries, no database of its own. I specifically didn’t add authentication by default, didn’t add persistence, didn’t try to parse Metabase’s payload into anything structured, because none of that serves the one job it has: look clean on screen and prove the concept works. Every one of those would have been solving a problem the video doesn’t have.
Was It Worth It?
The honest answer is I still haven’t recorded a single frame. What I have is twelve finished scripts, a working Docker setup, sample data with a few columns bolted on for the Actions episode, and now a small tool that exists purely because I couldn’t stand the idea of dead air waiting for an alert to fire.
That’s the pattern repeating again: the actual task was “write a script,” and somewhere along the way I built infrastructure for writing that script better. I noticed myself doing it this time, which I’m choosing to count as progress even if the behavior didn’t change.
The next step is genuinely simple: press record. I’m doing that before I find a reason to build anything else first.