Your Postgres database knows how the quarter went. Your team still exports CSVs to Slack because nobody wants to learn SQL and Tableau licenses cost real money.
Metabase is the open-source BI tool that shows up in that gap. ~50k GitHub stars, a visual question builder for people who do not live in SELECT statements, a SQL editor when they do, dashboards with filters and subscriptions, and optional embedded analytics in your own product. The OSS edition is AGPL; Metabase also sells Pro/Enterprise features, but the core self-host story is the jar or Docker image you run yourself.
What it actually does
Metabase does not replace Matomo or Google Analytics on your marketing site. It connects to databases and warehouses you already run — Postgres, MySQL, MariaDB, SQL Server, BigQuery, Snowflake, and dozens more via official and community drivers — and turns them into charts, tables, and shared dashboards.
Day-to-day wins:
- Questions without SQL — pick a table, filter, summarize, save. Good for ops, support, and founders who need answers now.
- Native SQL — when the GUI is not enough, same saved questions power dashboards.
- Dashboards — filters, auto-refresh, email/Slack subscriptions, fullscreen TV mode for the office wall.
- Permissions — group access down to databases, tables, or rows (sandboxes) for internal teams or embedded customer analytics.
- Embedding — iframe charts or full-app embeds in SaaS products (check license tier for advanced embedding).
- Data modeling — metrics, transforms, and library curation in newer releases for teams that outgrow ad hoc questions.
Metabot and agent APIs are the new AI layer: natural-language questions with guardrails, if you enable them. Self-hosters can treat that as optional; the point is still governed access to your warehouse, not a third-party BI cloud holding copies of your tables.
Why self-host?
Queries stay on your network. Metabase runs the SQL; results flow to browsers inside your VPN or TLS-protected subdomain. For Canadian orgs with customer PII in Postgres, keeping the BI tier on the same sovereignty footprint as the DB is simpler than approving another US SaaS subprocessors list.
Cost curve. Per-seat BI pricing hurts fast. A JVM container on a VPS plus Postgres for Metabase's own app metadata is predictable — you pay for RAM and DBA time instead of viewer licenses.
Embedding control. Product teams embedding dashboards in client portals often need SSO, row-level security, and audit logs. Self-hosted Metabase lets you wire auth and network policy without begging a vendor for a feature flag.
Open core clarity. AGPL covers the OSS build; commercial tokens unlock SSO, advanced caching, and some embedding modes. Read the license before you ship embedded analytics to paying customers — the split is documented upstream.
What running it takes
Fastest production path: docker pull metabase/metabase, point environment variables at a dedicated application database (Postgres recommended — not the default H2 file once you have real dashboards to lose). Default UI port is 3000. Java 25 JRE if you run the jar instead; Docker hides most of that.
Two-database mental model:
- App DB — stores Metabase users, saved questions, dashboard layout, pulses. Back this up religiously.
- Data sources — your production Postgres/MySQL/etc. Metabase only needs read access (plus write if you use transforms). Use a read replica for heavy explorers when you can.
Sizing: small teams often start on 2–4 GB RAM for the container; large dashboards and many concurrent users need headroom and possibly Metabase's caching (commercial) or careful question design. Run it as a systemd service or orchestrated container with health checks, not a jar you start manually on login.
Migrate off H2 before your team builds a library of questions on the default embedded DB — upstream docs spell out the migration path.
Who it's for (and who should skip it)
Good fit: startups with one Postgres app DB, agencies reporting across client schemas (with strict permissions), internal ops teams, SaaS companies embedding simple analytics, anyone who rejected "just use the admin panel export."
Maybe skip it: if you only need website traffic charts, use web analytics (we have posts on Matomo, GoatCounter, and friends). If you already standardized on Power BI with enterprise SSO everywhere, duplicating Metabase buys little. If nobody will curate questions and collections, you get 200 orphaned charts and call it failure — governance is still human work.
Hosting it in Canada
Metabase fits our Docker and VPS stacks: app DB on MariaDB/Postgres in-region, Metabase on a private port behind nginx, read-only DB users pointed at your app replica.
Tell us which databases you query, expected viewer count, and whether you need embed or SSO if you want a production env template before you invite the whole company.
Want BI your team will actually open? Talk with Swift Host — we are in St. Albert and actually answer the phone.
