#050: Getting Started w/ Metabase | Open Source Data Visualization

Metabase is a business intelligence tool for building charts and dashboards on top of a database, and the core product is open source and free to self host. You pull a Docker image, run a container, open it in your browser, and point it at your warehouse. From there you build what Metabase calls questions, group them into dashboards, write raw SQL when the point and click builder runs out, and save reusable models for your team. There is a paid cloud version, but nothing below requires it. The one thing to change before anyone depends on it is the embedded application database, which is meant for trying the tool out and not for production.

Install Metabase with Docker

Metabase's website leads with the hosted plan. The self hosted instructions sit further down, in the installation docs.

There are two ways to run it yourself: a Docker image, or a JAR file that needs Java installed. Docker is the easier path and the one I use.

Get Docker first

If you don't already have it, install Docker Desktop for Windows, Mac or Linux from docker.com. It takes a few minutes and you only do it once.

Make sure Docker is running before the next step, otherwise the commands below fail.

Pull the image and run the container

The quick start in the Metabase docs gives you two commands. The first fetches the prebuilt image from Docker Hub:

docker pull metabase/metabase:latest

The second starts a container from that image and maps it to a port on your machine:

docker run -d -p 3000:3000 --name metabase metabase/metabase

Open Docker Desktop and you'll see the image under Images and a running container named metabase. Click through to open it in a browser, or go straight to http://localhost:3000.

That is the whole install. No server to provision, no license, no account. The app is running locally in a container.

Set it up and connect your data

First launch drops you into a setup wizard: language, your name, and an email address for the admin account. Fill it in for yourself, since this is the login you'll use.

Next it asks for a database connection. You can skip this and add it later, but it's easier to do now.

Connecting a warehouse

I connected Snowflake. The connector list covers the usual options, so pick whichever one holds your data.

For Snowflake the fields are the ones you'd expect:

• Display name, whatever you want it called inside Metabase
• Account identifier, from your Snowflake URL
• Username and password, or a private key if you use key pair auth
• Warehouse, in my case a small developer warehouse
• Database and schemas, mine is analytics with all schemas included
• Role, a developer role rather than an admin one

One thing that trips people up: the database name is case sensitive. Type it exactly as it appears in your warehouse.

The last screen offers usage tracking and a newsletter. Both are optional.

Find your way around

The home screen immediately reflects your data. Mine picked up the two schemas in my Snowflake database, staging and marts, and surfaced them right away.

Collections

Collections are folders. You create one, name it, and save questions and dashboards into it to keep things organized by team or topic.

Everyone also gets a personal collection. That's where I park half finished work I don't want the rest of the team stumbling into.

X-rays

Those tiles with lightning bolts on the home page are X-rays. Metabase guesses what a table is about, infers column types, and generates a dashboard for you automatically.

It's genuinely useful for a first look at unfamiliar data. Save what you like into a collection.

Build a question and a dashboard

The New button in the top right is where everything starts. It offers three things:

• Question, a guided builder for one chart or table
• SQL query, for when you'd rather write it yourself
• Dashboard, a canvas that holds multiple questions in one view

The question builder

A question walks you through each step, which makes it workable for people who don't write SQL. I started from a customers table, joined orders on the matching customer ID, then filtered to customers whose total revenue was not zero.

Custom columns and summaries come from the same panel. Hit visualize, check the output, then save it into a collection.

Putting it on a dashboard

On save, Metabase asks whether you want to add the question to a dashboard. Say yes and create a new one if you don't have it already.

The dashboard editor is drag and drop. Resize the cards, arrange them, and save.

You can also drop in a text card, which accepts Markdown. Headings, italics, links and bullets all render, which is how you add context around the charts instead of leaving numbers to speak for themselves.

Write SQL, with variables and snippets

The guided builder covers a lot, but sometimes you already have the query. Paste it into the native SQL editor and run it.

The editor has a data reference panel beside it. You can inspect tables and views, see columns, and look at sample values while you write.

Variables

Anything you wrap in double curly braces becomes a variable, and Metabase adds an input box above the query:

select
    c.customer_name,
    o.order_id,
    o.amount
from analytics.marts.customers c
join analytics.marts.orders o
    on o.customer_id = c.customer_id
where c.customer_name = {{customer_name}}

Type a value into the box, run it, and Metabase substitutes it in. That turns one saved query into a reusable report.

SQL snippets

Snippets are reusable chunks of SQL, closer to a small function than a variable. You save a condition or a join once and reference it by name:

select *
from analytics.marts.orders
{{snippet: recent_customers}}

When the query runs, Metabase swaps the snippet for its stored SQL. Change the snippet once and every query using it picks up the change, which is what keeps a team's definitions aligned.

Changing the visualization

A saved query opens as a table. Switch it to a bar chart, pick the dimension and the measure, and save. Any dashboard showing that question updates with it.

Create a model

A model is an extra layer between the warehouse and the people building reports. It is a saved query that behaves like a table inside Metabase.

The case for it is simple. The thing in your warehouse is rarely the thing you want to report on, so somebody does the same joins and filters over and over.

Turning a question into a model

Take a question you've already built, open its options and convert it to a model. From there you can edit the query definition and, more usefully, edit the metadata.

Metadata editing is the part I'd recommend not skipping. Setting column types, categories and descriptions is what gives people enough control and context to use the model correctly.

Building on top of it

Once it exists, a model shows up as a data source alongside your real tables. New questions start from it, with the joins and filters already applied, so nobody reaches into raw warehouse tables.

Dashboard and admin settings

Three dashboard level options are worth knowing about:

• Bookmarks, which pin a dashboard to your sidebar for quick access
• Auto refresh, which re-runs the queries on an interval you pick
• Subscriptions, which send the dashboard to email or Slack on a schedule

Subscriptions matter more than they sound. Plenty of people never log into a BI tool, but they will read an email.

The admin section

Account settings hold your personal profile. The admin section is where the real configuration lives.

• Databases, to review or fix the credentials and defaults you set during setup
• Table visibility, to hide schemas people shouldn't build on. I hide staging so nobody reports off it by accident
• People, groups and permissions, to control who can see and do what

Segments and metrics

Two more admin features are easy to miss. A segment is a saved filtered slice of a table that people can reuse.

A metric is a saved calculation. Define total quantity as a sum once, and everyone uses the same definition instead of three analysts producing three numbers.

Before you use it in production

This is the step people skip. Metabase stores its own metadata, your questions, dashboards, users and settings, in an application database. By default that is an embedded H2 database inside the container.

H2 is fine for evaluating the tool. It is not meant for production, and losing it means losing everything you built.

Before anyone depends on your instance, point Metabase at a proper external database like Postgres or MySQL. The docs cover the configuration, and it is a connection string rather than a migration project if you do it early.

Metabase won't match a full featured commercial BI platform on every capability. But for building and sharing visuals on top of a warehouse, without a per seat bill, it covers more ground than most teams expect.

Related reading

• Don't Sleep on Open-Source Data Viz Tools
• The Hidden Cost of Open Source
• The 10 Key MDS Components: Part 1 (Essentials)
• The True Value of a Data Presentation Layer

Final takeaway

Cost is what usually stops a small team from putting real reporting in front of the business, and a container you run yourself removes that objection in an afternoon. The clients I've set this up for cared far more about having something people open than about the logo on it.