Self-service BI in 2026: revisit Apache Superset, Metabase and Lightdash before you build another dashboard

Most companies do not decide to “adopt a BI tool”. They drift into one. An analyst installs something on a spare virtual machine to stop emailing Excel files. Within a year the tool has two hundred saved queries, forty dashboards, three definitions of “net sales” and a login screen shared by half the company. Nobody remembers who set up the server, the version is four years old, and one day a sales head asks a simple question: “Can our dealers see their own numbers in the portal, and only their own numbers?”

That question is the moment this post is written for. Self-service BI looks like a charting problem, but the hard parts are elsewhere: who is allowed to see which rows, where the definition of a metric lives, how the tool is upgraded, what happens when a dashboard with twenty charts is opened by two hundred people at 10 AM, and which features are actually free under the licence you are reading.

This post revisits three open source BI tools in 2026: Apache Superset (the Apache Software Foundation project, 6.1 line, with 7.0 in release voting), Metabase (the friendly query builder with an open core) and Lightdash (the BI layer built on dbt and its own YAML semantic layer). We also look briefly at where Redash and Grafana stand, as context. The aim is not to pick the prettiest charts. It is to understand how each tool works, what its open source edition really includes, how it handles security and caching, and what running it for five years will look like.

A few pieces of news set the scene. Apache Superset 6.1.0 came out on 13 May 2026 and is still the latest stable release on 1 November 2026. The first release candidate of Superset 7.0 was withdrawn in October after a security related objection, and a second candidate is in its vote now; 7.0 brings a long list of breaking changes, including Python 3.11 as the minimum, SQLAlchemy 2.0 and a new access model called Subjects. Metabase shipped version 65 on 12 October 2026, with patch releases for the 65, 64, 63 and 58 lines at the end of October; 64 is the current long term support line. Lightdash moved to version 3.0.0 on 21 October 2026 and had reached 3.116.0 by 31 October, which tells you how fast it ships. Redash, quiet for years after 2021, has been releasing again since 2025, and its September 2026 release fixed 13 security advisories.

This post stays with dashboards and self-service exploration. If your real problem is a slow database under the dashboards, read real-time OLAP in 2026. For small questions on a laptop, in-process analytics in 2026 is the better starting point. Building clean models before they reach a BI tool is covered in data transformation in 2026, and finding and documenting datasets in data catalogs in 2026. If what you need is a form over a database rather than a chart, see internal tool builders in 2026, and for single sign-on in front of all of this, Keycloak and its alternatives.

A scenario to keep us honest

We will use one invented company through the post. Siruvani Pumps is an invented example, not a real business. It is a Coimbatore manufacturer of domestic and agricultural pumps and motors, selling through about 140 dealers across Tamil Nadu, Kerala and Karnataka. The company has about 340 people. The IT team has nine people, and the data team has three, led by Kavitha.

What they run today:

  • An ERP on PostgreSQL, with a read replica that the data team queries.
  • A small reporting warehouse, also on PostgreSQL, built every night with dbt Core: about 40 models covering sales, returns, warranty claims, dealer stock and collections.
  • A Redash 10.1.0 instance on a virtual machine, installed in 2021, with about 180 saved queries and 25 dashboards. Around 60 internal people use it: 12 who write queries and 48 who only view.
  • A daily Excel file per region, emailed to regional sales managers, built by a script that one engineer understands.

What triggered the review: three things arrived in the same quarter. The Redash 26.9.0 release notes listed 13 security advisories and recommended upgrading all installations, and the company is five years behind that. The sales head wants the dealer portal to show each dealer its own sales, stock and pending warranty claims. And in a quarterly review, finance and sales presented two different “net sales” numbers for the same month, because one dashboard subtracted returns and the other did not.

Kavitha’s questions: should we upgrade Redash or move to Superset, Metabase or Lightdash; which of them gives dealers safe access to only their own rows; where should “net sales” be defined so it is the same everywhere; what will it cost in licences and people; and can three of us run it for five years?

The short version

  • Define metrics before you choose a tool. Most “BI problems” are really two definitions of the same number. Put shared definitions in one place (your transformation models, or the tool’s semantic layer) and make dashboards read from there.
  • Apache Superset 6.1 is the fully open source option. Row level security, embedded dashboards with guest tokens, alerts and reports, OAuth and LDAP login are all in the Apache 2.0 code. The price is operations: a production install needs a metadata database, Redis and Celery workers, and the 7.0 upgrade will be a real project.
  • Metabase is the easiest for business users and quick to run as one container. The AGPL open source edition is generous for internal use, but row and column level permissions, SAML, OIDC and JWT login, serialization, modular embedding and granular caching are paid features. Plan for that before you promise them to anyone.
  • Lightdash is the best fit when your metrics already live in dbt. Its semantic layer, row filtering through user attributes and Google login are open source. Embedding, results caching, pre-aggregates, custom roles, enterprise SSO and the AI features need an Enterprise licence. It releases several times a day and has no long term support line.
  • Redash and Grafana are context, not the main contest. Redash is maintained again and worth upgrading if you are on it, but it is a SQL-first tool without a semantic layer. Grafana is excellent for operational and time series dashboards, and is not built as a business self-service tool.
  • For Siruvani Pumps, our plan is to move the “net sales” logic into dbt first, then run Metabase open source on the 64 long term support line for internal users, with guest embeds and a locked dealer parameter for the portal. If regional row permissions or SAML become mandatory, either buy Metabase Pro or move the dealer portal to Superset. Lightdash stays on the list if the dbt project grows into the centre of the data work.

Where things stand on 1 November 2026

Apache Superset

Apache Superset is an Apache Software Foundation project under the Apache 2.0 licence. The latest stable release is 6.1.0, published on 13 May 2026. Before that came 6.0.0 on 18 December 2025 and 5.0.0 on 23 June 2025. The 6.1.0 package on PyPI needs Python 3.10 or newer.

Superset 6.1 added an MCP service, so AI assistants can work with charts, dashboards and SQL through a separate process with JWT authentication, and a distributed coordination backend on Redis for locks and messages between processes.

Superset 7.0 is not released yet. The first release candidate was tagged on 13 October 2026 and its vote was cancelled after an objection linked to row level security for the public role. The second release candidate was tagged in mid October and its vote thread is still open; a tester has reported a pivot table regression, with a fix in review. The 7.0 upgrade notes are long. The main points are Python 3.11 as the minimum, SQLAlchemy 2.0, Playwright replacing Selenium for reports and thumbnails, global async queries rebuilt on a new task framework, owners and dashboard roles replaced by “Subjects” (users, roles and groups as editors and viewers), stricter SQL Lab defaults and startup checks that reject default JWT secrets. There is also a new semantic layer extension, switched off by default behind a feature flag.

Metabase

Metabase is open core. Code outside the top level enterprise folder is under the AGPL; code inside it, and the enterprise builds, are under the Metabase Commercial License. The open source build and the enterprise build are separate artefacts.

Metabase releases a major version roughly every month and marks some of them as long term support (LTS). According to its version support page, LTS lines get 14 months of support and other lines usually about two months. On 1 November 2026, version 65 (released 12 October 2026) is the newest, with support until 1 January 2027. Version 64, released on 16 September 2026, is the current LTS line, supported until 1 December 2027. Version 58, the previous LTS line, is supported until 17 February 2027. Version 63 reaches end of life today. Patch releases 65.2 and 64.4 came out on 30 October 2026, and 63.22 and 58.38 on 27 October.

Version 65 brought a “research mode” for the Metabot AI assistant, data apps as a paid beta, per-group control of MCP tool access on paid plans, an embedding hub, monitoring pages on paid plans, and tests for transforms. One change deserves attention from security teams: in 65, Metabot can see query results by default, which means those results are sent to the AI provider you configured. Admins can turn this off. Version 65 also restricts creating actions to admins.

Lightdash

Lightdash is also open core, with a different split. Code outside one enterprise folder in the backend is under the MIT licence. The enterprise folder is under the Lightdash Source Available License, which allows development and testing but needs an Enterprise subscription for production use.

Lightdash 3.0.0 was released on 21 October 2026. Its one breaking change concerns pre-aggregates, which no longer rebuild on every project compile. By 31 October 2026 the project was at 3.116.0. The upgrade documentation is honest about what this pace means: minor versions can include backwards incompatible changes, there is no LTS tag, and production installs should pin an exact image tag. A command line check, lightdash upgrade-check, reads a safety file published with each release and tells you whether a rolling update is safe or whether you need to stop the old version first.

Lightdash started as a BI layer for dbt projects and can now also read its own “Lightdash YAML” model files, without a dbt project.

Around them

Redash is a BSD-licensed SQL query and dashboard tool that started in 2013. Databricks acquired the company behind it on 24 June 2020. After v10.1.0 in November 2021, there were no releases until v25.1.0 in January 2025. Since then the community has shipped v25.8.0, v26.3.0 and v26.9.0 (24 September 2026). The 26.9.0 notes list 13 security advisories, including SQL injection through user email addresses in query annotations and view-only users bypassing query restrictions, and disable custom JavaScript visualisations by default. If you run Redash 10, upgrading is urgent regardless of what you decide next.

Grafana is AGPL-licensed and released 13.3.0 on 27 October 2026, together with patch releases for four older lines. It can query SQL databases and many other sources, and it is the natural home for metrics, logs and traces. For business users who want to explore sales data with filters and drill-downs, it is usually not the right fit, and this post does not compare it further. If that is your world, see infrastructure monitoring in 2026.

The first questions to ask

  1. Who will build, and who will only view? A tool loved by analysts can frighten a regional manager. Count builders and viewers separately; it matters for training and, with Metabase paid plans, for the bill.
  2. Where do metric definitions live today? If they are scattered across saved queries, the tool you pick will inherit the mess. If they already live in dbt, Lightdash becomes more attractive.
  3. Who must see only some rows? Regions, dealers, branches, customers. Row level security is the feature that most often decides the edition you need.
  4. Will people outside the company see dashboards? Embedding for customers or partners changes the security model and, for Metabase and Lightdash, often the licence.
  5. Which login do you need? Google, LDAP, OIDC or SAML through a company identity provider. Check each against the open source edition, not the feature page.
  6. How heavy are the queries, and what is the warehouse? A BI tool sends SQL to your database. If the database is slow, caching helps a little and a better data model helps a lot.
  7. Who will run it, and how often can you upgrade? One container and a monthly patch, or a set of services with a broker and workers. Be honest about the team’s time.

How each one works

Apache Superset: a Python web app with workers on the side

Superset is a Flask application with a React front end. Its documentation describes the production shape clearly:

  • The web application, which serves the UI and REST API.
  • A metadata database for users, charts, dashboards and saved queries. PostgreSQL and MySQL are the tested choices; SQLite is only for trying it out.
  • A cache layer, usually Redis, which caches query results and also acts as the message broker.
  • Celery workers and Celery beat, which run alerts and reports, scheduled cache warm-up, asynchronous SQL Lab queries and thumbnails.

A plain pip install gives you only the web application. Everything that needs the cache or workers will be missing or degraded until you add them. In the 6.1 default configuration, the data cache is a “null” cache, which means no query results are cached at all until you configure one.

Superset connects to databases through SQLAlchemy drivers. Users work in two places. SQL Lab is a SQL editor for people who write queries. Explore is the chart builder, which works on a dataset: either a physical table or a “virtual” dataset defined by a SQL query. Datasets can carry metrics and calculated columns, and dashboards combine charts with native filters and cross-filters.

Metabase: one Java process and an application database

Metabase is a Clojure application that runs on the Java virtual machine as a single process. You can run the official Docker image or the JAR file; the JAR documentation recommends Java 25 and says earlier versions are not supported. By default it listens on port 3000.

It keeps its own state, such as users, questions, dashboards and settings, in an application database. The default is an embedded H2 file, which the documentation says is not for production; production installs should use PostgreSQL (MySQL and MariaDB are also supported). There is a documented path for migrating away from H2 if you started with it.

Users ask questions, either through a graphical query builder or the SQL editor. Models are curated, documented starting points built from a question, and metrics are saved aggregations with their dimensions. Dashboards combine questions with filters, and alerts and subscriptions go out by email or Slack. In recent versions, Metabase has added a “Data Studio” area for modelling: data structure, a glossary, measures, segments and SQL transforms on self-hosted open source, with the curated “Library”, dependency graph and Git based remote sync on paid plans.

Lightdash: a semantic layer first, charts second

Lightdash reads your semantic definitions from YAML: either the meta sections of a dbt project or its own model files. Each model becomes a table you can explore, its columns become dimensions, and you declare metrics on top. When someone picks dimensions and metrics in the UI, Lightdash compiles SQL and runs it on your warehouse. People who need raw SQL can use the SQL runner.

A self-hosted install has more parts than people expect. The backend serves the API and UI, and an external PostgreSQL database holds application state, even for a proof of concept. S3-compatible object storage is required in production. A headless browser renders images and PDFs for scheduled deliveries and Slack previews. For larger installs, a scheduler worker handles deliveries and exports, and NATS with warehouse workers runs warehouse queries asynchronously. The official Docker Compose file shows the small version of this: the app, PostgreSQL with pgvector, MinIO and a headless browser. The documentation recommends Helm for production.

One setting needs special care. LIGHTDASH_SECRET signs session cookies and encrypts data at rest in the database. If you lose it, you lose access to that encrypted data, so store it like a database password.

Semantic layer and metrics

This is where the three tools differ most, and where the “two net sales numbers” problem gets solved or repeated.

Superset: metrics on datasets

In Superset, a metric is an SQL expression saved on a dataset, such as SUM(net_amount). Anyone with rights on the dataset can add one, and charts pick from the list. This works with few datasets and a careful owner, and gets messy when virtual datasets copy the same logic.

Superset 7.0 adds a semantic layer extension with “semantic layers” and “semantic views”, plus MCP tools to work with them. It is switched off by default and is new, so treat it as something to watch, not something to plan around this year.

Metabase: models, metrics and the paid Library

Metabase lets you define metrics with a data source, a formula and dimensions, and build models as curated starting points. The open source edition includes measures, segments and a glossary in Data Studio. The curated Library, verified models, official collections and dependency checks are paid. Metabase metrics live inside Metabase; if you want the same definition in a notebook or another tool, you have to copy it or move the logic down into the database.

Lightdash: metrics as code

Lightdash is built around metrics as code. Here is a small example in the dbt 1.10 style, with a metric and a row filter:

models:
  - name: fct_dealer_sales
    config:
      meta:
        sql_filter: ${TABLE}.dealer_code = '${lightdash.attributes.dealer_code}'
    columns:
      - name: net_amount
        config:
          meta:
            metrics:
              net_sales:
                type: sum

The definition is reviewed in a pull request, versioned with the model it describes and deployed with the CLI. Lightdash can also translate a supported subset of dbt MetricFlow metrics, so teams that already use MetricFlow do not need to define everything twice. An Enterprise feature, the Metrics SQL API, exposes the semantic layer over the PostgreSQL wire protocol so other tools can query metrics. It is in beta.

There is also an industry effort to make semantic models portable. Apache Ossie, an incubating Apache project formerly called Open Semantic Interchange, is a specification for exchanging semantic models between tools. Lightdash documents how its concepts map to Ossie, marked experimental, but it does not read or write Ossie files itself yet.

What we suggest

Whatever tool you choose, put the business logic that money depends on (net sales, returns, collections) in your transformation layer as named columns or tables. Let the BI tool’s semantic layer add simple aggregations and labels on top. Then a change in the tool does not change the number.

Security and access

Login

  • Superset uses Flask-AppBuilder for authentication: its own database users, LDAP, OAuth (which covers OIDC providers such as Keycloak, Google or Microsoft Entra ID) and remote user headers from a proxy. All of this is in the open source code. SAML is not built in; most teams put an OIDC provider in front.
  • Metabase open source supports its own passwords, Google sign-in and basic LDAP. SAML, JWT, OIDC, SCIM, single logout, group mapping from SSO and disabling password login are paid features.
  • Lightdash supports Google login on all plans. Okta, Azure AD, OneLogin, generic OIDC and SCIM are Enterprise features.

Row level security

  • Superset has row level security filters in the open source code. A filter is an SQL clause such as region = 'South' attached to datasets and to roles (in 7.0, to subjects). “Regular” filters apply to the listed roles; “Base” filters apply to everyone except the listed roles, which makes deny-by-default rules possible. Filters with the same group key are combined with OR, others with AND. Clauses can use Jinja templates such as the current username when template processing is on. One limit is easy to miss: in SQL Lab, row level security applies only if the RLS_IN_SQLLAB feature flag is on, and it is off by default. Our hands-on check below shows exactly this.
  • Metabase puts row and column level permissions (earlier called data sandboxing) and database-managed row level permissions in its paid plans. In the open source edition you can control access to collections and to whole databases or tables, but not to rows within a table.
  • Lightdash supports user attributes in the open source edition. A sql_filter on a model adds a row condition based on the user’s attributes, and required_attributes or any_attributes hide tables, columns or metrics. The documentation lists important gaps: the SQL runner, AI SQL mode, the MCP “run SQL” tool and custom SQL fields bypass these controls, chart and dashboard filters are not a security boundary, and scheduled deliveries run with the creator’s access.

The common lesson: a BI tool’s row security protects only the paths that go through its semantic model or dataset layer. Anyone who can write raw SQL against the same connection can see everything that connection can see. Give restricted users no SQL access, or give the BI tool a database user that can see only what the most restricted audience may see, and use separate connections for wider access.

Embedding

  • Superset supports embedded dashboards in the open source code through its embedded SDK. Your backend asks Superset for a short-lived guest token, which can carry row level security clauses, and the browser loads the dashboard with that token. Superset 7.0 enforces the allowed domains list for embedded dashboards and rejects default JWT secrets at startup.
  • Metabase open source includes “guest” embeds (earlier called static embeds), signed by your backend with a secret key. Parameters can be locked in the signed token, so a dealer cannot change the dealer code. On the open source and Starter plans these embeds show a “Powered by Metabase” badge. Modular embedding, the React SDK, full-app embedding with sign-in, tenant isolation and white-labelling are paid. Metabase counts people who sign in to interactive embeds as billable users; guest embeds do not count.
  • Lightdash embedding needs an Enterprise licence. Lightdash Cloud lists embedding as a paid add-on, priced per dashboard load.

Secrets, AI and data leaving the building

All three tools now have AI assistants and MCP servers. Before switching any on, decide which AI provider may receive schema names, SQL and query results; remember that Metabot in Metabase 65 sees query results by default. Superset’s MCP service can be limited with scoped API keys, and in Lightdash AI agents and MCP are Enterprise features.

Performance and caching

None of these tools makes a slow query fast. They send SQL to your database and draw the result. They can only avoid repeating queries, run long ones in the background and limit rows returned.

Superset

Superset caches through Flask-Caching. In production you configure a Redis-backed data cache with a timeout; datasets and charts can override it. Cache warm-up can be scheduled through Celery. Long SQL Lab queries can run asynchronously on workers, and dashboards can use global async queries so the browser is not blocked waiting for a slow database. In 7.0, global async queries move onto a new task framework and the old configuration keys are removed, which is one more reason to test that upgrade carefully.

Metabase

Metabase stores cached results in its application database when self-hosted. The open source edition gets the default caching policy, including the “adaptive” policy, which caches results for longer when a query takes longer to run. Duration and schedule based policies, per database, dashboard and question policies, and preemptive caching that refreshes results before users ask are paid features. Automatic cache refresh does not work together with row and column security or impersonation.

Heavy caching therefore makes the application database grow; watch its size.

Lightdash

In Lightdash, filter value caching is available on Cloud plans. Results caching for charts and dashboards needs Cloud or a self-hosted Enterprise licence and is off by default. When enabled, results are stored in S3, keyed by project and generated SQL, and expire after 24 hours by default, with a per-project duration between one minute and 30 days. Pre-aggregates, which keep materialised summaries and answer matching queries from them, are also an Enterprise feature. A self-hosted open source Lightdash therefore sends every query to the warehouse.

Reading vendor claims

We found no independent, comparable benchmarks across these three tools. Dashboard speed depends on the warehouse, the data model, charts per dashboard and caching. If a vendor page says a feature makes dashboards faster, read it as the vendor’s own run on its own data.

Licences and commercial models

Apache Superset: Apache 2.0, everything included

All of Superset’s features, including row level security, embedding, alerts and reports and the MCP service, are in Apache 2.0 code. There is no enterprise edition from the project. Commercial support and hosting come from companies such as Preset; check their terms separately.

Metabase: AGPL open source plus paid plans

The AGPL allows internal use, modification and self-hosting without paying. If you modify Metabase and offer it to users over a network, the AGPL asks you to make your modified source available to them, so talk to your legal team before building a customer product on a patched Metabase.

Metabase’s published list prices, excluding tax, as on its pricing page:

  • Open source: free, unlimited users.
  • Starter (cloud only): USD 100 a month including 5 users, then USD 6 per user per month.
  • Pro (cloud or self-hosted): USD 575 a month including 10 users, then USD 12 per user per month.
  • Enterprise: from USD 20,000 a year.

Annual plans are about 10 per cent cheaper on Starter and Pro. Everyone who signs in counts as a user, including viewers of interactive embeds.

Lightdash: MIT core plus source-available enterprise code

The MIT licence on the core is very permissive. The enterprise folder is source-available: you can read it and use it for development and testing, but production use needs a subscription. A self-hosted Enterprise install validates its licence key with Lightdash’s licensing service at every start, so plan network access for that.

Lightdash’s published pricing lists self-hosted open source with community support, Cloud Pro at USD 3,000 a month with unlimited users, and Enterprise on Cloud or on-premises at a custom price.

Redash and Grafana

Redash is BSD-2-Clause, a permissive licence. Grafana is AGPL-3.0, with paid Enterprise and Cloud offerings from Grafana Labs.

Operations and day two

Upgrades

  • Superset publishes an UPDATING.md file with every release. Read it fully. Run superset db upgrade and superset init after each upgrade, and take a metadata database backup before. The 6.x to 7.0 upgrade changes the Python version, the database library, the access model, the async query system and the screenshot engine at once. Our advice is to stay on 6.1 in production, wait for 7.0.0 to be released and for at least one patch release, and rehearse the upgrade on a copy of your metadata database.
  • Metabase releases monthly. If you cannot upgrade every month, run an LTS line (64 today) and move to the next LTS line once a year. Pin exact image tags, and back up the application database before every upgrade, because Metabase migrates it on startup.
  • Lightdash asks you to pin the image tag, upgrade at least monthly, test in a staging instance and back up the database first. Use lightdash upgrade-check to decide between a rolling update and a stop-and-start. With no LTS line, a small team must accept frequent change.

Backups

All three keep their important state in PostgreSQL (or MySQL for Superset and Metabase). Back it up and test a restore, as you would for any application database; PostgreSQL backups in 2026 covers the tools. For Lightdash, also keep LIGHTDASH_SECRET and the S3 bucket. For Superset, keep SECRET_KEY, which encrypts database connection passwords in the metadata database.

Content as code

  • Superset can export and import dashboards, charts and datasets as YAML bundles, so content can live in Git and move between environments.
  • Metabase serialization and the configuration file are paid features. On the open source edition, moving content between environments is mostly manual or through the API.
  • Lightdash keeps the semantic layer in Git by design, and its CLI can download and upload charts and dashboards as code.

Monitoring

Watch the application’s health, the metadata database and, most often forgotten, the load the BI tool puts on the warehouse. A dashboard with 20 charts opened by 100 people at a review meeting can send 2,000 queries to a database sized for a nightly batch. Give the BI tool its own database user so you can see and limit its queries.

Side by side

Licence

  • Superset: Apache 2.0, every feature.
  • Metabase: AGPL open source; paid plans under a commercial licence.
  • Lightdash: MIT core; enterprise folder source-available and paid for production.

Best user experience for non-technical viewers

  • Metabase is the simplest for people who have never written SQL.
  • Lightdash is simple once the semantic layer is well designed, because users only pick fields.
  • Superset is powerful but has more screens and options to learn.

Semantic layer

  • Superset: metrics and calculated columns on datasets; a new semantic layer extension behind a flag in 7.0.
  • Metabase: models, metrics, measures and segments; curated Library on paid plans.
  • Lightdash: metrics, dimensions and joins as YAML in Git, in dbt or Lightdash’s own format.

Row level security in the open source edition

  • Superset: yes, RLS filters on datasets; SQL Lab needs a feature flag.
  • Metabase: no; row and column permissions are paid.
  • Lightdash: yes, through user attributes, with documented bypass paths.

Single sign-on in the open source edition

  • Superset: OAuth/OIDC and LDAP, no built-in SAML.
  • Metabase: Google and basic LDAP; SAML, OIDC and JWT are paid.
  • Lightdash: Google; other SSO is Enterprise.

Embedding in the open source edition

  • Superset: yes, embedded SDK with guest tokens.
  • Metabase: guest embeds with signed, lockable parameters and a badge.
  • Lightdash: no, Enterprise only.

Caching in the open source edition

  • Superset: yes, configurable, usually Redis; off by default.
  • Metabase: yes, default and adaptive policies; granular and preemptive caching paid.
  • Lightdash: no results caching without Enterprise.

Operational weight

  • Superset: web app, metadata database, Redis, Celery worker and beat.
  • Metabase: one Java process and an application database.
  • Lightdash: backend, PostgreSQL, object storage, headless browser, plus workers as you grow.

A worked plan for Coimbatore

Month 1: fix the number, then the tool. Kavitha’s team writes down the 15 numbers that leadership reviews every month, with one owner each. “Net sales” is defined once, in a dbt model, as invoiced value minus returns minus credit notes, before GST. The same happens for “dealer stock” and “pending warranty claims”. A new mart, fct_dealer_sales, carries a dealer_code and a region on every row. The old Redash is upgraded in place to 26.9.0 as a stop-gap, because it will run for a few more months and its security fixes matter now.

Month 2: run Metabase open source for internal users. Metabase 64.4 on the LTS line runs as a pinned Docker image, with its application database on the company’s managed PostgreSQL, not H2. It connects to the reporting warehouse through a read-only database user. Login is Google Workspace sign-in, which the company already uses. The 12 builders recreate the 12 most-used Redash dashboards on top of the new marts, and the rest of the 180 saved queries are archived rather than migrated. Metabot stays off until the company has decided which AI provider may see sales data.

Month 3: dealer portal with guest embeds. The dealer portal backend signs a guest embed token for one dashboard, with dealer_code locked to the logged-in dealer. The dashboard reads only from fct_dealer_sales through a separate database connection whose user can see only the dealer-facing columns. The team tests changing the URL, editing the token and sharing links, and accepts the “Powered by Metabase” badge for now.

Month 4: decide on regions. Regional managers still need to see only their region. In the open source edition, the team does this with per-region saved questions in collections that only that region’s group can open, and no query builder access to the raw tables for viewers. This works for three states but is clumsy to maintain. If the company grows to more regions, or the auditors ask for SAML login, the plan is to price Metabase Pro: for 60 users that is USD 575 plus 50 extra users at USD 12, about USD 1,175 a month at list price, before tax. The alternative is to move the dealer portal to Superset, where row level security and embedding cost nothing in licence but more in operations.

What we did not choose and why. Superset would give Siruvani every security feature free, but a three person team would also take on Redis, Celery workers and a large 7.0 upgrade within a year, while the internal users need the gentlest learning curve. Lightdash fits the dbt project well, but embedding for the dealer portal needs an Enterprise licence and the fast release pace without an LTS line worries a small team. Staying on Redash was considered: after the upgrade it is safe, but it has no semantic layer and no row level security for the portal.

When not to adopt each

Do not adopt Apache Superset if

  • You have no one who can run Redis, Celery workers and a Python application in production.
  • Most users are non-technical viewers who want to click, not configure.
  • You need SAML and cannot put an OIDC provider in front.

Do not adopt Metabase if

  • Row level security, SAML or content promotion between environments are must-haves and there is no budget for a paid plan.
  • You plan to modify the source and offer it to customers without dealing with the AGPL.
  • You want metric definitions to be reusable outside the BI tool.

Do not adopt Lightdash if

  • You do not have, and do not want, a semantic layer in YAML, reviewed in Git.
  • You need embedding, results caching or enterprise SSO without buying a licence.
  • Your team cannot keep up with frequent upgrades and has no staging instance.

A short history

Redash came first, in 2013, as a simple way to write SQL and share charts; its story since 2020 is covered above.

Superset began at an Airbnb hackathon in 2015 as “Panoramix”, a web UI for the Druid database, with its first commit on 2 July 2015. It was renamed Caravel and then Superset, entered the Apache Incubator in May 2017, released 1.0 on 18 January 2021 and was announced as an Apache top level project on 21 January 2021.

Metabase started its public repository in February 2015 and published early releases that year. It built its name on letting people ask questions without SQL, and later added an enterprise edition, embedding and long term support lines.

Lightdash started in 2021 as an open source BI layer on top of dbt projects. It kept the semantic layer as code at its centre. Version 3.0.0 arrived in October 2026.

Decision guide

You run an old Redash and it mostly works

Upgrade to 26.9.0 now for the security fixes, then decide calmly. If you need no semantic layer, row security or embedding, a maintained Redash may be enough for SQL-first teams.

Your users are mostly non-technical and you need a tool next month

Start with Metabase open source on the current LTS line, with PostgreSQL as its application database. List the paid features you might need later and get a price before you promise them.

You need row level security and embedding without licence costs

Choose Superset 6.1, and budget for PostgreSQL, Redis, Celery workers and a 7.0 upgrade rehearsal.

Your metrics already live in dbt and your users are analysts

Try Lightdash. Its semantic layer will feel natural, and open source covers internal use with row filtering. Price the Enterprise licence early if embedding, caching or SSO beyond Google are on your list.

Checklist

  • Write down the top numbers leadership reviews, with one definition and one owner each.
  • Put money-related logic in the transformation layer, not in dashboard SQL.
  • Decide who builds and who views, and count both.
  • List every row level and column level restriction you need, and check it against the open source edition.
  • Check login requirements (Google, LDAP, OIDC, SAML, SCIM) against the open source edition.
  • Decide whether outsiders will see dashboards, and how embedding is licensed.
  • Use PostgreSQL for the BI tool’s own database, never the embedded default.
  • Give the BI tool read-only database users, with narrower users for restricted audiences.
  • Configure caching deliberately and watch the warehouse load during busy hours.
  • Pin exact versions and keep a staging instance.
  • Back up the metadata database and the secret keys, and test a restore.
  • Decide which AI provider may receive schemas and results before switching on AI features.
  • Archive old saved queries instead of migrating everything.

Common mistakes

  • Treating dashboard filters as security. A filter is a convenience. Only row level security, or a database user that cannot see the rows, is a control.
  • Forgetting the SQL editor. Row security in all three tools protects the modelled path. A user with SQL access on the same connection can often see everything.
  • Leaving the embedded default database in production. H2 for Metabase and SQLite for Superset are for trials only.
  • Assuming an open core feature page describes the free edition. Read the edition matrix line by line.
  • Upgrading Superset across a major version without reading UPDATING.md. The 7.0 changes touch access control, async queries and screenshots.
  • Running Lightdash latest. With several releases a day, an unpinned image can change behaviour without warning.
  • Switching on AI assistants before deciding where data may go.

A small hands-on check

We ran one small, safe check on our own box on 1 November 2026, between about 10:20 AM and 10:25 AM IST. Everything ran on 127.0.0.1 in a scratch folder, and the server was stopped afterwards. We did not try Metabase or Lightdash: there was no Java on the box for Metabase, and Lightdash needs several services.

What we did with Superset 6.1.0:

  1. Created a Python 3.12 virtual environment and ran pip install apache-superset==6.1.0 without version pins. The first superset db upgrade failed, because the resolver picked newer versions of some libraries (a newer Flask-Caching caused a startup error). Reinstalling with the pinned requirements/base.txt from the 6.1.0 release tag as constraints fixed it. Lesson: install Superset with the project’s pinned requirements or use the official Docker image.
  2. Initialised a SQLite metadata database (fine for a drill, not for production), created an admin user and started the server on 127.0.0.1. The health endpoint returned 200.
  3. Created a toy orders table with four regions (East 990, North 1500, South 1250, West 700), registered it as a database and dataset through the REST API, and asked the chart data API for total amount by region. All four regions came back.
  4. Created a “Regular” row level security filter with the clause region = 'South' on that dataset for the Admin role, and asked again. Only South, 1250, came back. The generated SQL showed the clause added to the WHERE part of the query.
  5. Ran the same aggregation as the same user through the SQL Lab API. All four regions came back, because RLS_IN_SQLLAB is off by default, exactly as the documentation says.

We also confirmed that the default 6.1 configuration uses a null data cache, so nothing is cached until you configure Redis or another cache. It was a behaviour check, not a performance test.

Unlearn, re-learn

  • Unlearn “BI is about charts”. Re-learn that BI is about shared definitions and safe access; charts are the last step.
  • Unlearn “open source means every feature is free”. Re-learn to read the edition matrix: Superset is all in, Metabase and Lightdash keep important features in paid editions.
  • Unlearn “a dashboard filter keeps data private”. Re-learn that only row level security or database permissions do that, and only on the paths they cover.
  • Unlearn “move every old query to the new tool”. Re-learn to rebuild the few dashboards that matter on clean models and archive the rest.

Sources

Apache Superset

Metabase

Lightdash

Around them

comments powered by Disqus

Releted Posts

Internal tool builders in 2026: revisit Appsmith, ToolJet and Budibase before you build another admin panel

Every growing company ends up with a second, quieter product: the screens its own staff use. Support needs to look up an order and resend an invoice.

Read more

Data catalogs in 2026: revisit OpenMetadata, DataHub and Apache Atlas before you add another metadata platform

Most teams do not decide to build a data catalog. They drift into needing one. A new analyst asks which of three “orders” tables is the real one.

Read more

Authorization in 2026: revisit OpenFGA, SpiceDB and Cerbos before you hard-code another permission check

Picture a SaaS company in Nagpur that sells loan-origination software to cooperative banks across Vidarbha and Marathwada (an invented example, not a real client).

Read more