Superset

Last reviewed Sep 13, 2026 · 879 words

Superset is the right self-hosted BI pick when your analysts write SQL and you have more than 5 of them. Below that line, Metabase gets you 80% of the value for a quarter of the operational effort, and I would send most homelabbers and small teams there first. Superset earns its 74,623 GitHub stars at the other end of the scale: dozens of chart types, a serious SQL IDE, row-level security, and dashboards that survive being shared with 200 people. It is Apache-2.0 with no enterprise edition holding features back, which is rarer than it should be in this category.

The bundled compose file is a demo, not a deployment

The repository ships a docker-compose setup that starts Superset, PostgreSQL, Redis, Celery workers and a beat scheduler, and the maintainers say plainly that it is not for production. It is still the fastest way to see whether you want this at all: clone, docker compose -f docker-compose-image-tag.yml up, wait 3 or 4 minutes for the init container to load examples, and log in on port 8088 with the demo admin account. Budget an hour for that evaluation and do not let it become the thing you run. The example data alone adds hundreds of megabytes and the default SECRET_KEY is public.

What a real install needs: four services and one Python file

A production shape is Superset plus PostgreSQL for metadata, Redis for caching and the Celery broker, and at least one Celery worker for async queries and scheduled reports. The catalogue lists 512 MB as the floor; that is the web process idling. With workers, a cache and a couple of active users, plan on 2 to 4 GB. Configuration lives in a single superset_config.py mounted into the container:

SECRET_KEY = "generate-with-openssl-rand-base64-42"
SQLALCHEMY_DATABASE_URI = "postgresql+psycopg2://superset:pw@db:5432/superset"
CACHE_CONFIG = {"CACHE_TYPE": "RedisCache", "CACHE_REDIS_URL": "redis://redis:6379/0"}

Two gotchas cost people days. First, changing SECRET_KEY after the first run breaks every stored database password, so pick it once and back it up with the metadata database. Second, Superset speaks to your data sources through SQLAlchemy drivers that are not all in the base image; connecting to ClickHouse, Trino, BigQuery or even MySQL means building a small image that pip-installs the driver. Keep a Dockerfile with a FROM apache/superset line and a RUN pip install line under version control, because you will rebuild it on every upgrade.

Point it at replicas, never at the primary

Superset runs whatever SQL a user types, and SQL Lab makes exploratory queries pleasant, which is exactly how an unindexed join ends up scanning your production Postgres at 09:30 on a Monday. Give it a read-only role on a replica, set the per-database query timeout in the connection settings (30 seconds is a sane default, 300 for the analysts' warehouse), and enable async execution through Celery so a long query does not pin a web worker. If most of your data already sits in one Postgres, the Postgres for everything pattern of a dedicated reporting schema with materialised views pays off here more than anywhere.

Where it loses to Metabase and Grafana

Metabase is one Java process, has a question builder non-technical staff genuinely use, and takes 10 minutes to stand up. If the people asking for dashboards cannot write SQL, Superset's chart builder will frustrate them and Metabase will not. Grafana wins for anything time-series or operational; Superset can chart Prometheus data through plugins but it is the wrong tool for a NOC screen. Superset's territory is analytical dashboards over warehouse tables for people who want a SQL editor two clicks away, plus embedding: its guest-token embedded dashboards are the best free option for putting analytics inside your own app. The wider analytics category covers the web-analytics tools that people sometimes confuse with BI.

Upgrades and backups are one and the same problem

Everything that makes your instance yours is in the metadata database: connections, saved queries, charts, dashboards, users, row-level security rules. Dump it nightly with pg_dump alongside superset_config.py and your custom image definition, and you can rebuild from nothing in 20 minutes. Upgrades run superset db upgrade migrations against that database; read the release notes for the major version bumps because deprecated chart types do get removed, and take a dump immediately before each one.

What I'd do

If you are a team of fewer than 5 with a mixed technical audience, run Metabase and revisit this in a year. If you have SQL-literate analysts, a warehouse or replica to point at, and someone willing to own a Celery setup, Superset is the strongest open-source BI tool you can self-host and the licence will never surprise you. Build a custom image with your drivers, pin the version tag, put it behind a reverse proxy with SSO, and give it a replica with a query timeout on day one. Skip the Helm chart unless you already run Kubernetes for other reasons; four containers in Compose on a 4 GB VM handle a surprising amount of dashboard traffic.