Metabase vs Superset vs Lightdash: open-source BI compared (2026)

Quick answer (2026)

If you want a BI tool you can run, extend and embed without ever having a licence conversation, run Apache Superset. It is Apache-2.0 across the whole tree, and we checked for a restricted directory rather than assuming: enterprise/ and ee/ both return HTTP 404 on the repository. There is no second edition. The bill arrives as operational weight instead, and it is the largest of the three.

If you want the shortest path from "we have a Postgres database" to "the finance lead built her own dashboard", run Metabase. Its open-source build is a genuinely complete BI tool, and the commercial code is not merely licensed differently, it is a separate binary you never download. What sits behind that licence is narrower and more specific than most write-ups claim, and we corrected our own first reading of it below.

Run Lightdash only if you already run dbt, because there is no path through this product that does not involve a dbt manifest. That single fact explains its data-source list, its 2.8 GB image and most of its appeal.

What this comparison is not about

ShipGarden has covered two adjacent categories, and readers arrive at all three looking for different things, so it is worth drawing the line before the numbers start.

This is not about open-source internal tools like Appsmith, ToolJet and Budibase. Those exist so somebody can write to your database through a form you assembled. BI tools here are read paths. If your requirement contains the word "update" or "approve", you want the other article.

It is also not about self-hosted product analytics like PostHog, Plausible and Umami. Those instrument your frontend and answer questions about visitors. BI queries the store your application already writes to, and answers questions about the business inside it.

Metabase turns up on Retool-alternative lists constantly, and that is a category error worth naming: it does not build interfaces, it queries them.

The one decision that determines everything else: where the model lives

Every difference below follows from a single architectural choice each project made about where a metric definition is allowed to exist.

Lightdash puts the model in your dbt project. The DbtProjectType enum in packages/common/src/types/projects.ts lists eight options: dbt, dbt_cloud_ide, github, gitlab, bitbucket, azure_devops, none and manifest. Read that list carefully. Every single entry is a different way of getting a dbt manifest in front of Lightdash. none does not mean "no dbt", it means no git integration. There is no non-dbt path. Your metrics live in YAML in your repository, they are reviewed in pull requests, and Lightdash is the interface over them.

Metabase puts the model in Metabase. Models, metrics and segments live in its own metadata database. That is why a non-engineer can build one, and it is also why moving that work between environments is a real project rather than a git push.

Superset puts the model in Superset datasets, defined in its metadata database, with Jinja templating available in the SQL. It sits between the other two: more structure than ad-hoc questions, less version control than a dbt repo.

If you already have a dbt project, Lightdash's approach is close to free and the other two feel like duplicating work. If you do not, it is a prerequisite you must adopt before you see a single chart.

The three licences, read on September 6, 2026

Every roundup calls all three "open source". Two of them are more complicated than that, and GitHub itself declines to classify them: the API reports Apache-2.0 for Superset and NOASSERTION for both Metabase and Lightdash. That is the signal to stop reading badges and open the file.

Superset ships one LICENSE.txt, 11,585 bytes of stock Apache License 2.0. It is an Apache Software Foundation project. We probed for a restricted directory and found none.

Metabase ships a four-paragraph LICENSE.txt that splits the repository by directory. Outside the top-level enterprise/ directory, files are AGPL. Inside it, they carry the Metabase Commercial License. The part most comparisons omit is the paragraph after that, which is about binaries rather than source: images at hub.docker.com/metabase/metabase are released under the AGPL, and images at hub.docker.com/metabase/metabase-enterprise are released under the commercial licence. The enterprise/README.md is blunter still, stating that access to the files "does not constitute permission to use this code or Metabase Enterprise Edition features", and the build is switched with MB_EDITION=ee.

So the commercial code is compiled out. If you pull the OSS image, the restricted features are not sitting on your disk waiting to be switched on. They are absent.

Lightdash takes the opposite approach to the same problem. Its root LICENSE puts everything under MIT except packages/backend/src/ee, which carries "The Lightdash Source Available License" from Telescope Technology Limited. That licence permits modification and patching, and restricts use in production to holders of a valid Enterprise Subscription. It says so directly, and it also carves out an exception that most summaries drop: you may copy and modify the software "for development and testing purposes, without requiring an Enterprise Subscription".

The Lightdash finding, and the milder reading that turned out to be the correct one

Lightdash's dockerfile copies the whole backend source tree into the image with COPY packages/backend/src/ ./packages/backend/src/, and separately references an ee path by name when copying package manifests. The restricted directory is therefore inside the image you pull, unlike Metabase where it is compiled out.

Our first reading of that was that self-hosters are shipped code they are forbidden to run, which is a dramatic claim and would have been the most quotable line in this article. It is also wrong in the way that matters.

Reading packages/backend/src/ee/licenses/index.ts settles it. The module exports a validateLicenseKey function that POSTs a key to a remote validation endpoint and throws an AuthorizationError when the key is missing, invalid, suspended or expired. Its first branch is explicit: if no key is supplied it raises "License key is required for license validation". The enterprise surface is wired through a LicenseClient in ee/index.ts.

So the honest version is: the code ships, and it is gated at runtime against a remote licence check. You are not going to breach that licence by accident, because without a key the features do not start. What you can do by accident is assume the feature list on the website describes the instance you just deployed.

That distinction matters because of what is in the directory. packages/backend/src/ee contains scim, preAggregates, postgresWire, scheduler, authentication, analytics, and a substantial set of AI agent models. The repository describes Lightdash as "Agentic BI. Analytics at the speed of code". The agent layer is in the commercial directory. preAggregates is the primary performance lever for BI on large tables, and postgresWire lets other tools query the semantic layer over the Postgres protocol. Those are not garnish.

The Metabase correction, because "SSO is paid" is not true as usually stated

The enterprise tree carries 60 modules, and the names read alarmingly: sso, scim, mfa, sandbox, advanced_permissions, serialization, audit_app, database_routing, tenants, metabot, semantic_search. It is easy to write "Metabase puts SSO behind a paywall" from that list. We nearly did.

Then we looked for an open-source counterpart, and there is one. src/metabase/sso/ in the AGPL tree contains google.clj, ldap.clj and a complete oidc/ directory holding discovery.clj, tokens.clj, schema.clj, state.clj and check.clj. That is a real OIDC implementation, not a stub.

The enterprise sso/integrations/ directory contains google.clj, jwt.clj, ldap.clj, oidc.clj, saml.clj and saml_utils.clj. Compare the two sets and the line falls in a specific place: saml.clj and jwt.clj have no open-source counterpart, while Google, LDAP and OIDC exist in both trees.

The accurate statement is therefore that Metabase's OSS build can authenticate against an OIDC provider, and that SAML and JWT signed embedding are commercial. Not "SSO is paid". This is the second time in two ShipGarden cycles that an open-core project has turned out to have two copies of a feature, one on each side of the licence line, and it is now our default assumption rather than a surprise.

We did not establish what the enterprise copies of Google, LDAP and OIDC add over the open-source ones. See the section on what we did not measure.

What each one costs you to run

We pulled the compressed layer totals straight from the Docker registry API for linux/amd64 rather than quoting a docs page.

Two things in that table are worth more than the numbers.

The first is that Metabase's two images really are two artifacts, 44 MB apart. That is the licence split made physical.

The second is an inversion that catches people out: Superset has the smallest image and by far the largest deployment. Its own docker-compose-non-dev.yml defines seven services, not one: redis, db on postgres:17, superset, superset-init, superset-worker, superset-worker-beat and superset-websocket. Async queries, alerts, scheduled reports and cached thumbnails all run through Celery, so the worker and the beat scheduler are not optional extras once you use the product properly. Metabase, by contrast, is one process and a database.

And Lightdash's 2.8 GB is not carelessness. Its dockerfile builds nine separate Python virtual environments, one per supported dbt version from 1.4 through 1.12, each with its own set of warehouse adapters covering Postgres, Redshift, Snowflake, BigQuery, Databricks, Trino, ClickHouse, DuckDB and Athena. It also installs fonts-noto-cjk so headless chart screenshots render CJK glyphs. A tool whose model lives in dbt has to ship dbt, and it has to ship every dbt your projects might pin. The image size is the architecture, printed.

What you can actually connect to

This is the axis most likely to end the decision before licensing gets a vote.

Lightdash's supported set is exactly bigquery, postgres, redshift, snowflake, databricks, trino, clickhouse, athena and duckdb.

Read what is missing. There is no MySQL. No SQL Server. No Oracle. No MongoDB. If your application database is MySQL, Lightdash is not a tool you are choosing between, it is a tool you are ruling out, and no amount of licence comparison changes that. Metabase ships drivers for mysql, sqlserver, oracle and mongo among others. Superset reaches the widest set through SQLAlchemy.

This is a consequence of the model decision, not an oversight. Lightdash supports the warehouses dbt supports, because Lightdash runs dbt.

Where each one loses

Superset loses on time-to-first-chart and on who can use it. Seven services is a real operational commitment, and the dataset and chart authoring flow assumes someone comfortable with SQL and with the tool's own concepts. It has 74,663 stars and only 592 open issues, which is a healthy ratio for a project of its age, but none of that helps on the afternoon you are debugging a Celery beat worker.

Metabase loses on governance and on portability. Row-level data sandboxing, advanced permissions, audit logging, SCIM provisioning and serialization all sit in enterprise/. Serialization is the one to watch if you care about treating dashboards as code, because exporting and importing content between environments is exactly the workflow an engineering team expects to have. It is also the project carrying 4,401 open issues, by far the most of the three.

Lightdash loses on prerequisites and on the gap between the marketing and the MIT build. It is the youngest project by six years, created in March 2021 against 2015 for both others, and it has 6,119 stars against Superset's 74,663. If you do not run dbt, adopting Lightdash means adopting dbt first. If you do run dbt, it is the only one of the three where your metric definitions are already reviewed, versioned and diffable, which is a genuinely strong position that neither competitor can match.

What we did not measure

Stating this plainly rather than implying coverage.

We did not run any of the three. Every figure here comes from published licence files, source trees, dockerfiles, compose files and the Docker registry API, read on September 6, 2026. There are no benchmarks in this article and no query timings.

We did not establish what Metabase's enterprise google.clj, ldap.clj and oidc.clj add over their open-source counterparts. We established only that the open-source ones exist and that saml.clj and jwt.clj do not appear outside enterprise/.

We did not price anything, deliberately. Every recommendation above rests on licence structure, supported data sources, deployment shape and where the model lives. All four are architectural, and none of them changes if a vendor updates a pricing page next week.

We did not count Superset's 74 engine spec files by hand for false entries. That figure includes shared files such as base.py, so treat it as an upper bound on distinct engines rather than an exact count.

If you are choosing today

Run Superset if the widest possible data-source support matters, if you want one licence with no directory exceptions anywhere, and if you have the appetite to operate a multi-service deployment.

Run Metabase if the people asking the questions are not engineers. Its OSS build is complete BI, the commercial code is a different binary you never pull, and the honest boundary is that governance features, SAML, JWT embedding and serialization sit on the other side of it.

Run Lightdash if you already have a dbt project and your warehouse is on its list of nine. Go in knowing the image carries a commercial directory gated behind a remote licence check, that the agent features headlining the repository live in it, and that preAggregates does too.

If your data lives in MySQL, that decision is already made for you.

Sources we read directly

• Metabase LICENSE.txt, the AGPL and commercial split, including the paragraph about which Docker images carry which licence.
• The Lightdash Source Available License, covering packages/backend/src/ee.
• Apache Superset's docker-compose-non-dev.yml, the seven-service reference deployment.
• Lightdash's dockerfile, where the nine bundled dbt environments are declared.