Metabase: The Open-Source BI Tool That Ends Per-Seat Analytics Licensing — Read the License Files First
The most expensive part of a BI tool is never the software. It is the fact that you have to decide, in advance, who is allowed to ask a question.
Every organisation that grows past a certain size develops the same bottleneck. Somebody in operations wants to know how many tickets were closed last week. Somebody in marketing wants to know which campaign produced the paying users. Somebody in finance wants a number before a board meeting. All three of them need a query, and exactly one person on the team can write SQL.
So they ask that person. That person becomes a queue. The queue becomes a two-day turnaround on simple questions. Eventually somebody buys a BI tool, discovers the per-seat pricing, and then the real problem appears:
if you charge per creator, people stop creating. The tool that was supposed to democratise data access instead rationed it, because every additional seat is a line item somebody has to approve.
Metabase exists to break that particular logjam. Roughly
48,000 GitHub stars, self-hostable, unlimited users, and a visual query builder designed so that a person who has never written a JOIN can answer their own question. It has been around since 2015, it is written in Clojure on the JVM, and it is by most measures the dominant self-hosted BI option on the planet.
It is also a project with
four separate license files at the repository root, a license that GitHub reports as
NOASSERTION, SSO behind a commercial paywall, and a default database configuration that will silently destroy your work. None of those make it a bad choice. All of them are things you should know before you build a company's reporting layer on it.
This is a deep-dive on what Metabase actually is, what the open-source edition genuinely includes, where the commercial boundary sits, what it costs to run, and the specific mistakes that turn a successful deployment into a bad afternoon.
1. What Metabase Is
Metabase is a
business intelligence and analytics layer that sits between your databases and the people who need answers from them. It does not store your business data. It connects to your existing databases and warehouses, queries them, and presents the results as tables and charts.
That distinction matters more than it sounds. Metabase is a query broker, not a data platform. It is not a warehouse, it is not a transformation layer, and it should not be your canonical definition of what "monthly active user" means. Get the modelling right upstream — in dbt, in your warehouse, in your ETL — and Metabase becomes a very pleasant window onto it. Try to make Metabase the source of truth for business logic and you will build something fragile.
The product splits into three audiences:
- Non-technical users get a visual "Question" builder: pick a table, filter, summarise, group, visualise. No SQL.
- Analysts get a SQL editor with variables, snippets, and the ability to save queries as reusable "Models."
- Everyone gets dashboards, filters, alerts, and scheduled subscriptions to email, Slack, or a webhook.
2. The Problem It Solves: Per-Seat Analytics Tax
The economics of proprietary BI are built around a distinction between people who
create and people who
view. Tableau's Creator licence runs at a level where every additional analyst is a budget conversation. Viewer licences are cheaper but still per-head. The result is a predictable pattern: organisations buy a handful of creator seats, the analysts become a bottleneck again, and the expensive tool reproduces the problem it was purchased to solve.
Metabase's open-source edition has
no user limit. Everyone in the company can have an account, ask questions, and build dashboards. The marginal cost of the fiftieth user is zero.
That is not a small difference. It changes the social dynamics of data access. When asking a question is free, people ask questions. When it requires a licence approval, they ask a person instead, and that person becomes the bottleneck you were trying to eliminate.
The trade, and there is one, is governance. Unlimited creators means unlimited slightly-different definitions of the same metric. Metabase's answer is Models and Metrics — curated, reusable definitions that analysts create and business users build on. It works, but it requires someone to actually curate. Free access without curation produces forty dashboards with forty definitions of revenue.
3. The Question Builder
This is where Metabase earns its reputation, and it is worth being specific about why.
The visual builder walks a narrow path: start from a table, optionally join it, filter rows, summarise by a grouping, sort, limit. Each step is visible and editable, and each step previews its result. A user who understands "I want the count of orders grouped by month, filtered to last year" can express that without knowing what
GROUP BY does.
Two design choices make it work:
It is honest about the SQL. The builder shows you the query it is constructing and lets you drop into the SQL editor at any point. There is no wall between the two modes. This means the visual builder is a learning tool rather than a cage — people start visually and graduate to SQL naturally.
Summarisation is a first-class step, not an afterthought. Most visual query tools are built around "pick columns, filter rows" and bolt aggregation on awkwardly. Metabase treats "group by X and count" as a normal thing to want, which is what most business questions actually are.
The limits are real too. Complex window functions, recursive queries, multi-step transformations, and anything requiring a CTE chain will push you into the SQL editor. That is fine — that is what it is for — but anyone promising that "nobody will ever need SQL" is selling something.
4. The SQL Editor, Models, and Metrics
The SQL editor is CodeMirror 6 based, with autocompletion against your connected schemas, support for variables and field filters, and saved snippets. Language packs include SQL, Python, JavaScript, HTML, and JSON — the Python one is a tell that notebook-style authoring is coming to the Documents feature.
Models are saved queries that behave like tables for downstream questions. This is the governance mechanism: an analyst defines the canonical "active subscription" query once, and everyone else builds on that Model rather than re-deriving it. When the definition changes, it changes everywhere.
Metrics are the next layer — named, reusable aggregations defined in the Data Studio. Combined with Models, they give you something approaching a semantic layer, though it is not a full LookML-style contract and should not be treated as one.
The architectural advice that follows from this:
put durable logic upstream. Version your transformations. Define metrics in your warehouse or in dbt where they can be tested and reviewed. Use Metabase Models to expose those curated objects to business users. Metabase is excellent at consumption and presentation; it is a mediocre place to do data engineering.
5. Dashboards, Alerts, and Subscriptions
Dashboards support filters, auto-refresh, fullscreen presentation, and custom click behaviour — clicking a bar can drill down into the underlying rows, which is the feature that makes dashboards actually used rather than glanced at.
Alerts fire when a query result crosses a threshold you set: revenue below X, error count above Y, signups flat for three days.
Subscriptions deliver dashboard or question results on a schedule — daily, weekly, monthly — to email, Slack, or a generic webhook. The webhook option is the useful one for automation: it turns any Metabase question into an event source for the rest of your tooling.
Documents are a newer long-form feature: a rich text editor (TipTap 3) where you can interleave prose with live query results. It is aimed at the "here is the analysis, and here is what I think it means" use case that dashboards handle poorly.
The REST API and Automation
Everything the web interface can do, the REST API can do. That is not marketing — it is a documented, stable surface covering questions, dashboards, cards, collections, users, permissions, and query execution, with session or API-key authentication.
In practice this is what turns Metabase from a dashboard tool into a piece of infrastructure. Some patterns worth stealing:
Provisioning. Create users, assign groups, and set permissions from your own provisioning scripts rather than by hand. New analyst joins, gets an account with the right table access, no clicking.
Scheduled extraction. A saved question can be executed via API and the result consumed by anything. If you need a nightly CSV of yesterday's signups landing somewhere, that is a cron job and a token, not a manual export.
Alerting beyond email and Slack. The webhook subscription covers most cases, but the API lets you build alerting logic that Metabase does not natively express — composite conditions, escalation paths, routing by business hours.
Configuration as code. Collections, permissions, and dashboard definitions can be scripted and versioned. For a team that wants its analytics layer reproducible rather than hand-assembled over eighteen months, this is the difference between a tool and a system.
The one thing to plan for is rate and load: an aggressive script hammering expensive queries through the API will hurt the same source database a slow dashboard would. Point it at replicas and cache the results, same as everything else.
6. Metabot, MCP, and the AI Layer
Metabase has been adding AI capabilities, and the implementation is more interesting than the marketing.
Metabot is the built-in assistant: ask a question in natural language, get a query and a chart. Treat it with appropriate caution. Natural-language-to-SQL is genuinely useful for
discovery — "what tables mention invoices?" is a good question for it — and genuinely unreliable for
authoritative reporting, because a plausible-looking wrong query is worse than no query at all.
More interesting is
MCP support. The repository depends on
@modelcontextprotocol/ext-apps, and Metabase exposes an agent API that lets external systems query your data programmatically. This means you can wire your own LLM tooling into Metabase with your curated Models as the surface area — which is a materially better design than letting a model generate SQL against raw tables, because the Models encode your governance.
If you are building internal AI tooling over company data, that architecture — semantic layer first, model second — is the right way round, and Metabase gets it right.
7. The Architecture
The backend is
Clojure, managed via
deps.edn, with the Clojure CLI version pinned in the Dockerfile for reproducible builds. The JVM target is
Java 21 (Eclipse Temurin), which brings virtual threads and modern GC behaviour. Build automation runs through Babashka scripts.
The frontend is React and TypeScript, but the bundler is
Rspack, not webpack — there are eight separate Rspack configs at the project root producing independent bundles for the main app, the embedding SDK, the iframe embed wrapper, and static visualisation rendering. That separation is meaningful for a product that ships analytics as an embeddable component.
Package management is
Bun, not npm or Yarn, with the lockfile committed and
bun install --frozen-lockfile in the Dockerfile. There is one charming bootstrap quirk: the builder stage installs Bun
via npm. You need npm to get Bun, and then Bun does everything else.
Notable frontend dependencies:
Mantine 8.3.18 for UI components (with a local patch file, which tells you the team hit a bug and fixed it rather than waiting upstream),
CodeMirror 6 for SQL editing,
TipTap 3 for rich text,
TanStack Table with virtualization for large result sets, and
@locker/near-membrane-dom — a Salesforce sandbox library that isolates embedded components so untrusted code cannot escape. Its presence is a signal about how seriously the embedding path is treated.
The database driver architecture splits cleanly:
modules/drivers/ for the core set,
enterprise/backend/ for commercial drivers. That directory split is the open-core boundary made visible in the source tree.
8. Installation
The standard path is Docker:
``
bash
docker run -d -p 3000:3000 \
--name metabase \
-e MB_DB_TYPE=postgres \
-e MB_DB_DBNAME=metabase \
-e MB_DB_PORT=5432 \
-e MB_DB_USER=metabase \
-e MB_DB_PASS=<password> \
-e MB_DB_HOST=<your-postgres-host> \
metabase/metabase
`
Note the environment variables. Do not skip them. Which brings us to the single most important section in this article.
The alternative is the JAR:
`
bash
java -jar metabase.jar
`
Same requirement, same trap.
9. The H2 Trap: Read This Before You Deploy
By default, Metabase stores its own application metadata in an embedded H2 database inside the container.
That metadata is everything: your users, your saved questions, your dashboards, your alerts, your permission configuration, your connection settings. H2 is embedded, which means it lives in the container's filesystem.
When the container restarts, it can be gone. Not "might be" — if you are running Metabase in Docker without a persistent volume on the data directory, a restart or a rebuild of the container puts you back at the setup wizard. Every dashboard. Every question. Every user.
This is the most common catastrophic Metabase failure, and it is entirely preventable in one of two ways:
Option one: mount a persistent volume so the H2 file survives restarts. This is acceptable for evaluation and personal use and nothing else.
Option two, which is the correct one: use an external PostgreSQL or MySQL database for the metadata store. Set MB_DB_TYPE=postgres
and the related variables at first launch. Do it on day one, because migrating from H2 to Postgres later is possible but is exactly the kind of migration you do not want to be doing under time pressure.
There is a third consideration that gets less attention: H2 does not handle concurrent load or growth well. The application database gets busy — query history, session data, cached results all land there. An external Postgres is not just about durability, it is about the thing not becoming slow and flaky as usage grows.
If you take one operational lesson from this article: configure an external metadata database before you create your first dashboard.
10. Connecting Your Data
Metabase connects to roughly twenty-plus officially supported sources: PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, Databricks, SQL Server, Oracle, MongoDB, Presto, Athena, ClickHouse, and more. Community drivers extend the list further.
Two pieces of advice on drivers:
Use official drivers for anything production-critical. Community drivers are self-host-only, unsupported by Metabase, and inherit whatever maintenance attention their author still has. They are a technical risk, not a core dependency.
Connect read replicas, not primaries. Metabase queries live databases. An enthusiastic user building a dashboard with a wide date range on an unoptimised table can produce a query that hurts your production database. Point Metabase at a replica, or at a warehouse, and the failure mode disappears.
There is also a security dimension worth naming explicitly: Metabase stores database credentials, and anyone with sufficient Metabase permissions can run arbitrary SQL against those connections. Your Metabase instance is, effectively, a SQL shell with a friendly face. Treat its permissions with the seriousness that implies.
11. Permissions and Governance
The open-source edition includes a real permissions model: group-based access control at the database, schema, and table level, with the ability to restrict who can write SQL versus who can only use the visual builder.
What is not in the open-source edition:
- SSO / SAML — commercial tier.
- SCIM provisioning — commercial tier.
- Advanced audit logs — commercial tier.
- Row-level and column-level permissions (sandboxing) — commercial tier.
- Advanced caching controls — commercial tier.
This is the open-core boundary, and it is worth being precise about it rather than hand-wavy. For an internal team that authenticates with email and password and does not need per-row data separation, the free tier is complete. For an organisation that needs SAML, or that needs to guarantee a regional manager only sees their own region's rows, the free tier is not sufficient and you are looking at a commercial licence.
The comparison that matters: against competitors that gate the same features, Zulip for example puts SAML, LDAP, and SCIM in its Apache-2.0 open-source edition at no cost. Metabase does not. That is a legitimate business decision and it is also a real line item in your evaluation.
12. Embedding: The AGPL Trap
Here is where you need to read license files.
The repository root contains four of them:
LICENSE.txt
— the overview.
LICENSE-AGPL.txt
— the open-source edition, AGPL-3.0.
LICENSE-EMBEDDING.txt
— terms specific to embedding.
LICENSE-MCL.txt
— the Metabase Commercial License.
Internal use is unrestricted. You can deploy Metabase inside your company, modify it, run it for thousands of users, and the AGPL imposes nothing on you, because you are not distributing it.
The AGPL network clause activates when you expose modified Metabase to users over a network. If you embed Metabase analytics into a customer-facing SaaS product and you have modified the source, those modifications must be released under AGPL-3.0. Embedding into a product you sell is precisely the situation the clause was written for.
This is the trap that catches SaaS teams. "We'll just embed Metabase in our app" is a very common plan, and it requires a commercial licence unless you are prepared to open-source your modifications. It is not a hidden gotcha — it is documented, explicitly, in a file at the root of the repository — but it is a file most people do not read until it matters.
If you plan to embed Metabase in a customer-facing product, read LICENSE-EMBEDDING.txt
before you ship a single pixel.
13. The Open Core Question
Metabase's repository license shows as NOASSERTION on GitHub, because there are multiple licenses and GitHub cannot determine which applies. This is not deceptive — the README is clear that the repo contains both the AGPL open-source edition and commercial editions — but it does mean the "open source" label carries an asterisk.
Let us be fair about the size of that asterisk.
Metabase is not one of the projects that relicense retroactively, or that ship a crippled "community edition" with the useful parts removed and then argue about the definition of open source. The open-source edition is the genuine product. It has been AGPL since the beginning. Unlimited users, unlimited dashboards, the full query builder, the SQL editor, Models, alerts, subscriptions, and the REST API are all in it.
What is commercial is the enterprise periphery: SSO, SCIM, audit logs, sandboxing, advanced caching, official support, and some database drivers. That is a defensible split, and it is more honest than several alternatives.
But it is a split. If your evaluation criterion is "everything I need must be in the open-source edition," you need to check your specific requirements against that list rather than assuming.
14. Where Your Data Goes
The self-hosting argument for Metabase is unusually strong, and it is worth stating precisely.
Your business data never leaves your infrastructure. Metabase queries your databases and renders results in your browser. It does not copy your data to a vendor cloud. It does not need to. This is fundamentally different from a SaaS BI tool, which by definition must hold a copy of, or a live connection to, your data on its own infrastructure.
The application metadata is yours too. Users, dashboards, questions, and query history live in the database you configured in section 9. On hardware you control.
Jurisdiction matters here. Metabase, Inc. is a Delaware C-Corp, which means its hosted offering is subject to the US CLOUD Act — US authorities can potentially compel access to data held by US providers. Self-hosting eliminates that exposure entirely, because there is no US provider in the loop. For a European company with GDPR obligations, or any organisation with data-residency requirements, this is often the decisive argument rather than a footnote.
One caveat on telemetry. The default build includes @snowplow/browser-tracker
, which is usage analytics. If your deployment has strict requirements about outbound connections, investigate and disable it. It is not covert — it is a listed dependency — but "self-hosted" and "no outbound connections" are different claims, and Metabase's default build satisfies the first more than the second.
The honest summary: self-hosting Metabase shifts the entire compliance burden onto you. Encryption at rest, TLS termination, network isolation, backups, access reviews — all of it becomes your responsibility rather than something covered by a vendor's SOC 2 report. That is the trade you are making. For many organisations it is the right one, because it converts "trust a vendor's audit" into "control your own," but it is work, not a checkbox.
15. What It Actually Costs
| Component | Tableau-class SaaS | Metabase self-hosted (OSS) |
|---|---|---|
| Creator licences | Per user, per month | $0, unlimited users |
| Viewer licences | Per user, per month | $0, unlimited users |
| Embedding | Custom / expensive | Commercial licence required |
| SSO / SAML | Usually included | Commercial tier |
| Infrastructure | $0 | ~$20–50/mo for a small VM |
| Metadata database | $0 | ~$15–30/mo managed Postgres, or $0 on existing |
| Maintenance | None | Upgrades, backups, monitoring |
A realistic small-team self-hosted deployment: a 2-vCPU / 4 GB VM plus a small managed Postgres runs somewhere in the range of $35–80 per month depending on provider and region. Run the Postgres on a box you already have and it drops substantially.
Compare that to a handful of BI creator seats at commercial rates and the arithmetic is not close. At ten users the saving is four figures a month. At fifty users it is the kind of number that shows up in a board deck.
The costs that are easy to miss: your time, for upgrades and maintenance; the metadata database, which people forget to budget; and the commercial licence, if you turn out to need SSO or embedding. Price the third one early, because discovering it after you have built the integration is an unpleasant conversation.
16. Metabase vs the Field
Apache Superset (~65k stars, Apache-2.0) is the more extensible, engineering-led option: richer custom visualisation plugins, a genuinely permissive license, and a steeper learning curve. Choose it when your users are mostly comfortable with SQL and you want to build custom visuals. Choose Metabase when your users are not.
Grafana (~76k stars, AGPL-3.0) is the right tool for time-series and infrastructure observability and the wrong tool for business analytics. If your question is "what is CPU doing," Grafana. If it is "which cohort converts best," Metabase. There is overlap and people use both.
Redash is the lighter, SQL-first option. Simpler, smaller operational footprint, less dashboard polish.
Looker is the governed semantic model answer — if your primary requirement is a rigorous, versioned metric contract enforced across many teams, LookML is a genuine capability Metabase does not fully match. It is also priced accordingly.
Metabase's position is the middle: the best self-service experience for non-technical users, the fastest time from installation to first useful dashboard, and the most approachable governance model. It wins on UX and loses on extensibility.
17. Honest Limitations
The H2 default is hostile. Covered in section 9, and it deserves its own line in the limitations list because it has destroyed real deployments.
SSO and sandboxing are paywalled. If you need them, price the commercial tier before you commit.
It is a query broker, not a data platform. No transformation layer, no lineage, no warehouse. Get that wrong and you will build something unmaintainable.
Natural-language querying is not yet dependable for authoritative numbers. Useful for discovery, risky for reporting.
Performance is your database's performance. Metabase queries live sources. Slow source queries produce slow dashboards, and no amount of Metabase tuning fixes an unindexed table scan. Caching helps; indexes help more.
Commercial drivers create a dependency on Metabase's release cycle and pricing.
The open-core boundary means "free" and "sufficient" are different questions. Answer the second one.
Clojure is a hiring constraint. If you plan to modify Metabase substantially, you need Clojure skills, and that is a smaller talent pool than Java or Python. With roughly 500 contributors and a bus factor around 10, it is not a fragile project, but it is not a shallow one either.
18. Performance and Caching
Metabase's performance profile is almost entirely downstream of two things: the queries it generates and the database answering them.
Caching is available, with per-question and per-dashboard TTLs, though the finer-grained controls sit in the commercial tier. For most teams, caching a handful of expensive dashboards with a five or ten minute TTL eliminates the majority of perceived slowness.
The real optimisation happens upstream. Index the columns you filter and group by. Partition large fact tables by date. Consider pre-aggregating the queries that appear on every dashboard. If a dashboard takes thirty seconds, the fix is usually a materialised view or a summary table, not a Metabase setting.
The application database also needs attention. Query history and session data accumulate. Plan for its growth and its backups like any other production database, because it is one.
A useful rule of thumb: if a query is slow in psql`, it will be slow in Metabase. Do not debug it in Metabase.
19. Troubleshooting
"I restarted and everything is gone." H2, no persistent volume. See section 9. Restore from backup or, if there is none, start over and configure Postgres this time.
"The dashboard never finishes loading." Run the underlying query directly against the source database. Ninety percent of the time it is a missing index or an unfiltered full scan.
"Users cannot see a table." Permissions. Metabase's group-based model is granular, and a new database defaults to restricted for most groups.
"SSO is not in the settings." It is a commercial feature.
"My embedded dashboard shows a login page." Embedding requires proper configuration of signed embedding tokens, and on the commercial side, the right licence.
"Upgrades broke something." Read the release notes before upgrading. Metabase ships frequently, and major versions occasionally change behaviour. Take a metadata database backup first, every time.
"Connection refused to the database." Check network path and credentials, then check whether the source database has a connection limit you have exhausted. Metabase holds a pool.
20. Backup and Upgrades
Your backup surface is small and clear:
- The application metadata database — the critical one. Users, questions, dashboards, permissions. Automate it. Test restores.
- Configuration environment variables — keep them in whatever you use for secrets management, not in a shell history.
Note what is
not in that list: your business data. It was never in Metabase. That is an underrated benefit of the architecture — the thing you most need to protect is not in the tool at all.
Upgrade discipline: back up the metadata database, read the release notes, upgrade in a staging environment if the deployment matters, and keep the previous container image around until you have confirmed the new one works. Metabase releases often — the cadence is a positive signal about project health — but "often" means you need a process rather than an ad-hoc approach.
21. Security Posture
Running Metabase self-hosted means owning security rather than inheriting it.
- TLS termination. Put it behind a reverse proxy with proper certificates.
- Network isolation. Metabase needs to reach your databases; it does not need to be reachable from the public internet.
- Credential handling. Metabase stores database credentials. Access to Metabase is effectively access to those databases, scoped by the permissions you configure.
- Regular updates. You are now responsible for applying security patches.
- Audit. If you need audit logs, that is a commercial feature — factor it in.
The project itself scores reasonably on OpenSSF criteria (around 7.2 out of 10), has no published security advisories in recent scanning, and maintains a documented security disclosure policy. It is a serious project with serious practices. That is different from saying your deployment is automatically secure.
22. Who Should Run It, and Who Shouldn't
Run it if you have non-technical people who need data and a technical bottleneck feeding them; if per-seat BI pricing is rationing access; if you want analytics over data that cannot leave your infrastructure; or if you need dashboards and alerts over an existing Postgres or warehouse.
Think twice if you need SAML or row-level sandboxing and cannot pay for it (budget for the commercial tier, or look at alternatives that include it); if you need to embed analytics in a customer-facing product (read the embedding license and price it); if your primary workload is time-series observability (Grafana); or if you need a rigorous semantic layer as the central contract (Looker, or dbt plus something else).
Do not run it if you are going to leave it on the default H2 database in production. That is not a configuration preference. It is a scheduled outage.
23. The Verdict
Metabase is the best self-hosted BI tool available, and the reason is not the feature list — several competitors have more features. It is that Metabase is the only one where a non-technical colleague can go from "I wonder how many..." to an actual answer without asking anyone, and without you paying a per-seat fee for the privilege.
The asterisks are real and manageable. Four license files mean you should read at least two of them. SSO is commercial. Embedding is commercial unless you open-source your changes. The AGPL network clause is a genuine constraint for SaaS products. And the default database configuration will destroy your work if you let it.
None of that changes the core proposition:
unlimited users, unlimited dashboards, your data on your infrastructure, for the cost of a small VM. Against a per-seat BI contract at commercial rates, the saving is measured in thousands per month, and the thing you get back that you cannot buy is the ability to give everyone in the company access to data without asking permission first.
Just configure Postgres. Before you build the first dashboard.
Related
Comments (0)
No comments yet. Be the first to comment!