Preparing for Apache Superset 7.0: Breaking Changes and an Upgrade Plan

Apache Superset 7.0 is in its release-candidate phase. The project published 7.0.0rc1 on 13 October 2026 and 7.0.0rc2 on 16 October 2026 for community testing and voting. The final release had not been announced on the research date, but the upgrade notes are already long, and several changes are breaking.

This article summarises the changes most likely to affect a self-managed Superset deployment, explains the trade-offs behind them, and proposes an upgrade plan. It is based on the project’s UPDATING.md at tag 7.0.0rc2; re-check it against the final release before you schedule work.

Where the release stands

The Apache Superset releases page lists 7.0.0rc1 and 7.0.0rc2 as pre-releases. The rc2 notes mention fixes since rc1, including row-level security rules for the public role now applying to anonymous users, an access error instead of a blank page for charts a viewer cannot read, and Redis or Valkey Sentinel support in the WebSocket server.

The UPDATING file for 7.0.0 is substantially longer than for 6.0.0 or 6.1.0. That reflects a release that changes the access model, the ORM, the screenshot stack and several defaults at once. A release candidate can still change, so treat the items below as a planning baseline, not a final list.

The access model moves to Subjects

The largest functional change is how access is assigned. According to UPDATING.md, Superset now uses subject-based assignments for dashboards, charts, datasets, alerts and reports, and row-level security (RLS). A Subject can represent a user, a role or a group.

• owners is replaced by editors for dashboards, charts, datasets and alerts or reports.
• Dashboard roles and the DASHBOARD_RBAC feature flag are replaced by dashboard and chart viewers, enabled with ENABLE_VIEWERS.
• RLS roles is replaced by subjects.
• The legacy junction tables, such as dashboard_user, dashboard_roles and rls_filter_roles, are migrated and dropped on upgrade.

One warning deserves attention. If you once used DASHBOARD_RBAC and later disabled it, stale rows in dashboard_roles will become active dashboard viewers after migration unless you remove them first. Any script or integration that reads or writes owners through the API also needs to change.

The trade-off is a cleaner, more expressive model in exchange for a one-way migration. Back up the metadata database, export current assignments, and plan a review of who can see and edit what after the upgrade.

Runtime and dependency changes

Change	What it means for operators
Python 3.10 support removed	Superset requires Python 3.11 or higher. Update virtual environments, base images and CI first.
SQLAlchemy 1.4 to 2.0; flask-sqlalchemy 3.1.1	Custom db_engine_specs, plugins and extensions that use removed patterns, such as Engine.execute(), must be updated. Some optional connector extras remain capped; check yours.
Selenium removed; Playwright required	Reports and thumbnails use Playwright with Chromium. Selenium-only config keys, including WEBDRIVER_TYPE and WEBDRIVER_CONFIGURATION, are removed.
Default Docker image is batteries-included	The default image bundles common drivers, MCP server dependencies and a headless Chromium. The previous minimal image is published under -lean tags.
Helm chart adopts Kubernetes recommended labels	A helm upgrade against an existing release fails on immutable selectors. Delete affected workloads before upgrading, or reinstall. This is a one-time migration.
Global Async Queries re-platformed	Async chart data runs on the Global Task Framework. The /api/v1/async_event/ API and several GLOBAL_ASYNC_QUERIES_* config keys are removed with no deprecation window.

If you build your own image on top of the old minimal default, switch the base to the matching -lean tag to keep your current footprint. If you rely on the default image, expect a larger image that needs fewer custom layers.

New defaults that change behaviour

Several features that were opt-in now ship enabled, and some exposures are now off by default. UPDATING.md lists, among others:

• Soft delete is on, and purging is live. Deleting a dashboard, chart or dataset archives it. A nightly task permanently removes archived objects after SOFT_DELETE_RETENTION_DAYS, 30 days by default. The first live run can remove a large batch; the notes suggest a dry run first to size it.
• Version history is on. Every save writes version rows, so the metadata database grows with edit volume. A beat task prunes old versions.
• Tagging is on. Saves and favourites write tag rows, and exports gain a tags key that importers on 5.x and earlier reject.
• Swagger UI is off. The OpenAPI documentation endpoints are no longer exposed unless enabled.
• Build details are admin-only. The git SHA and build number are hidden from non-admin users by default.
• SQL Lab denies more by default. PostgreSQL large-object routines and the SQL-standard information_schema views are added to the deny lists. Tooling that introspects information_schema through Superset needs a deliberate override.
• A SQL parse-length cap. Scripts larger than SQL_MAX_PARSE_LENGTH are rejected before parsing; very large virtual-dataset SQL may need the limit raised.

If your deployment replaces CELERY_CONFIG rather than inheriting it, the notes say you must carry the new retention task imports and beat entries. Otherwise purging and pruning will not run as expected.

These defaults reduce exposure and make deletions recoverable, which we consider sensible. They also add background work and metadata growth, so size the metadata database and monitor the new tasks.

URLs, templates and the front end

Integrations and bookmarks are a common source of surprise. In root deployments, routes such as /superset/dashboard/<id>/ now respond at /dashboard/<id>/. A new middleware redirects enumerated legacy paths for one release cycle. The SQL Lab path /superset/sql/<id>/ is not redirected and returns 404; bookmarks must move to /sqllab/?dbid=<id>.

Two further changes affect content and customisation:

• The from_dttm and to_dttm Jinja variables, deprecated since 5.0, are removed. Virtual datasets and custom SQL that use them must move to get_time_filter().
• Ant Design moves from v5 to v6. Internal CSS class names were renamed, so custom CSS that targets .ant-* internals can silently stop matching.

Search your dashboards’ CSS, your virtual datasets and any external links before the upgrade, not after users report broken pages.

The built-in MCP service

Superset includes a built-in Model Context Protocol (MCP) service that lets AI clients list dashboards, query datasets, execute SQL and create charts. The 6.1.0 section of UPDATING.md already describes MCP tool observability, and 7.0 tightens the service further:

• When JWT authentication is enabled, MCP_JWT_AUDIENCE must be set; the service now fails to start without it.
• Structured tool outputs are opt-in through MCP_STRUCTURED_OUTPUT_ENABLED, after validating every client and bridge.
• The MCP response size guard uses a byte limit instead of an estimated token count.

The MCP server deployment and authentication guide adds the operating controls. RBAC is enabled by default and checks each tool against Superset permissions. MCP_DISABLED_TOOLS removes tools such as execute_sql at startup. The guide warns that development mode without authentication must never be used in production, that the service applies no rate limiting of its own, and that tool results are user-controlled data with no instruction authority.

Our view: treat MCP as a new client of your BI layer. Start with read tools, disable execute_sql unless there is a clear case, and put the endpoint behind a gateway with rate limits.

Timing and an upgrade plan

Who should upgrade first

Not every deployment needs 7.0 on release day. Teams on 6.0 or 6.1 with heavy customisation, many API integrations or Helm-managed clusters carry the most migration work. They benefit from waiting for the first patch release while rehearsing the upgrade in staging. Teams with a lightly customised deployment, or those that need the new access model, can move sooner after testing.

Whatever the timing, run the rehearsal on a copy of production metadata. The Subjects migration, the first soft-delete purge and the new tagging rows all act on real metadata, and their effects are hard to judge on an empty test instance.

Upgrade steps

1. Wait for the final 7.0.0 release and re-read its UPDATING.md; note any changes from rc2.
2. Back up the metadata database and export dashboards, charts and datasets.
3. Move runtimes to Python 3.11 or later, and test custom engine specs and plugins against SQLAlchemy 2.0.
4. Replace Selenium settings with Playwright, and choose the default or -lean image.
5. Clean stale dashboard_roles rows, then rehearse the Subjects migration on a copy of production metadata.
6. Update API clients that use owners, async-event endpoints or /superset/ paths.
7. Replace from_dttm/to_dttm and review custom CSS for Ant Design v6.
8. Decide on soft delete retention, version-history retention, tagging and SQL Lab deny lists; run a purge dry run.
9. For Helm, plan the one-time workload recreation; then upgrade staging, test reports and alerts, and review access with business owners.

How Bassirah can help

We help teams plan and rehearse Superset upgrades, migrate access models, update custom plugins and harden the MCP service. Our Superset support is independent engineering; upstream fixes follow the community’s timeline, as set out in our open-source support model. See our Superset page and embedded analytics architecture.