Should a 6.x team start the Apache Superset upgrade to 7.0 now?
Yes, start planning now, but do not schedule the production cutover until the final 7.0 release is published. The GitHub releases page lists 7.0.0rc2 as a pre-release dated October 16, 2026, so the version is in testing and its breaking changes are settled enough to plan around. A release candidate is still a moving target, so treat this window as preparation: inventory what your 6.x deployment depends on, confirm each item against the UPDATING.md notes, and build a staging copy that you can rebuild when a later candidate or the final tag arrives. Confirm the final release date and any changes between the candidate and the final tag with the Apache Superset project before you commit to a date.
The notes in UPDATING.md are the authority for what changes, and they cover items that affect planning well before cutover: the Python 3.11 minimum, the SQLAlchemy move from 1.4 to 2.0, the removal of Selenium in favor of Playwright for report and thumbnail screenshots, the Ant Design 6 frontend, the replacement of owners with subjects, and the move of Global Async Queries to the Global Task Framework. Each of these can require work by a platform, data, or security team, so the planning question is who owns each item and how long it takes to verify, not whether the upgrade is coming. Ask your own engineers, and any partner you consider, to map each item to a specific component in your environment.
The supported path is the documented upgrade sequence. Back up the metadata database first, then run superset db upgrade and superset init, and test the result in staging before anything reaches production. Your staging environment should match production closely enough to surface problems with dashboards, reports, row level security, and the worker and caching components, because those are where breaking changes tend to appear. Keep the 6.x environment available as a rollback point until the staging results are signed off, and agree with the business owners of dashboards and reports on what a successful test looks like before the window opens.
What changes in Superset 7.0 and what each change asks of you
This table lists the breaking changes named in the UPDATING notes after Superset 6.1.0, with the impact on a self-hosted deployment and the action to take before the 7.0 upgrade. Read each row as a work item for your staging environment, and confirm every row against the final UPDATING.md because 7.0 is still in release candidate form.
| Change | Impact | Action needed |
|---|---|---|
| Python 3.10 removed, Python 3.11 or higher required | Hosts, base images and virtual environments on Python 3.10 will not run 7.0. Drivers and wheels pinned for 3.10 may also fail to install. | Build the 7.0 runtime on Python 3.11 or higher, rebuild images and reinstall database drivers, then test connections to every query engine. |
| SQLAlchemy 1.4 moved to 2.0 with flask-sqlalchemy 3.1.1 | Custom code, database dialect packages and metadata queries written for SQLAlchemy 1.4 may behave differently or fail. | Check custom extensions and dialect packages for 2.0 compatibility and run the metadata database migration in staging before production. |
| Selenium removed, Playwright required for reports and thumbnails | Alert, report and dashboard thumbnail screenshots stop working unless Playwright and Chromium are available to the workers. | Install and configure Playwright in worker and web images, then send test reports and check thumbnail output on large dashboards. |
| Ant Design 6 frontend with renamed internal CSS classes | Custom themes, CSS overrides and custom visualization plugins that target internal class names may render incorrectly. | Inventory custom CSS and plugins, retest them against 7.0, and review branding in a staging build. |
| Owners, dashboard roles and RLS roles replaced by subjects, owners become editors | Ownership-based access and API calls that read or write owners change meaning. Access reviews and automation built on owner fields need revalidation. | Export current owner, role and RLS assignments before upgrading, map them to users, roles or groups, and update any scripts or API clients. |
| Global Async Queries run as Global Task Framework tasks | Async query behavior, worker configuration and task visibility change, which affects deployments that rely on Celery-based async queries. | Confirm the worker and caching layer configuration for 7.0, then test async queries and monitor task execution under realistic load. |
| Swagger UI off by default unless SUPERSET_ENABLE_SWAGGER_UI or FAB_API_SWAGGER_UI is set | Teams or tools that open the API documentation page will find it disabled after upgrade. | Decide whether the API docs should be exposed at all, set the flag only where needed, and record the decision for your security review. |
Preparing the Apache Superset upgrade: backups and inventory first
Superset 7.0 changes Python, SQLAlchemy, screenshot tooling, the front-end library and the ownership model at once, so each change needs a recorded starting point. The six cards below produce the backups, inventories and test environment that let your team roll back and compare behavior before anything reaches production.
Verified metadata database backup
Take a full backup of the metadata database and restore it into a scratch instance before running superset db upgrade. A backup that has never been restored is not evidence. Record the database version, which must fall within the supported range of PostgreSQL 10 to 17 or MySQL 5.7 and 8.x, and confirm the restore completes and Superset starts against it. Sign-off: the database owner and the platform lead.
Custom visualization plugin inventory
List every custom chart plugin, its source repository, and the Superset and Ant Design versions it was built against. Ant Design 6 renames internal CSS classes, so plugins that style against those classes will need changes and tests. Record which plugins the business relies on so they receive priority testing. Sign-off: the product owner for analytics and the team that maintains the plugins.
Configuration and Docker build changes
Export superset_config.py and every environment variable that feeds it, including SECRET_KEY handling, auth settings, and any Swagger UI flags. Confirm whether Swagger UI must stay on, since it is off by default unless SUPERSET_ENABLE_SWAGGER_UI or FAB_API_SWAGGER_UI is set. Review custom Dockerfiles against the new base image expectations, and keep the image tag and build recipe under version control. Sign-off: the platform engineering lead and the security owner.
Owners, dashboard roles and RLS export
Export ownership for dashboards, charts and datasets, along with dashboard role assignments and row level security role bindings. The notes describe owners becoming editors and roles, users and groups replacing these bindings as subjects, which is a breaking change to both API and metadata. Store the export as a reviewable file and produce a before and after comparison in staging. Sign-off: the data governance lead and the owners of sensitive datasets.
Python 3.11 runtime and driver check
Superset 7.0 requires Python 3.11 or higher and removes support for Python 3.10. Confirm the runtime in every image and virtual environment, then test each database driver the deployment loads, since drivers compiled or pinned for older Python may fail. SQLAlchemy moves from 1.4 to 2.0 with flask-sqlalchemy 3.1.1, so verify that each custom database engine spec still connects. Sign-off: the platform engineering lead and the database team for each connected source.
Staging that mirrors production
Build a staging environment with the same metadata database engine, caching layer, worker setup, and copies of production data source connections where policy allows. Include the report schedules and alerts, because Playwright must produce screenshots there and the scheduled outputs need comparing with production. Keep test data masked where regulations apply. Sign-off: the analytics owner who approves dashboard test results and the security owner who approves data handling in staging.
Apache Superset upgrade sequence with checks and rollback points
This sequence moves a production Superset 6.x deployment to the 7.0 line through a staging rehearsal, so that each stage has a passing check and a known rollback point before production changes begin.
Confirm the target in UPDATING.md
Read the breaking change notes for every release after your current 6.x version in the project's UPDATING.md, and record the Python, SQLAlchemy, Playwright, Ant Design 6, subjects and async query changes that touch your deployment. The team lead and the platform engineer sign off on a written change list that names the 7.0 release candidate you will test, which is 7.0.0rc2 at the time of writing. Confirm the final release tag on the releases page before the staging build, because release candidates can change. Done when every item on the change list has an owner and a disposition of fix, accept or not applicable.
Clone production into an isolated staging environment
Create a staging copy with the same Superset configuration, a copy of the metadata database, the same authentication provider settings and the same caching and worker topology as production, using a separate database and secret values. Disable scheduled reports and alert delivery in staging so that test runs do not email real recipients or write to production channels. The platform engineer confirms that staging connects only to test copies of analytics databases. Done when a staging login succeeds through the production identity provider and a sample dashboard renders with the same data as production.
Back up the metadata database before any change
Take a full, restorable backup of the metadata database in production and a second copy in staging, then restore the production backup into a scratch database to prove it loads. Record the Superset version, the Alembic migration revision and the SECRET_KEY reference in the change record, and store the key in your secrets manager, since upgrades that touch encrypted fields depend on it. This backup is the first rollback point: if any later step fails, you restore it and redeploy the 6.x image. Done when the scratch restore completes and a query against the restored database returns the expected dashboard and user counts.
Build the Python 3.11 image with Playwright
Build a new Superset image on Python 3.11 or higher, since 7.0 removes Python 3.10 support, and install Playwright with its Chromium browser in place of Selenium. Pin the SQLAlchemy 2.0 line and flask-sqlalchemy 3.1.1 that the notes name, and rebuild every database driver against the new runtime. Keep the 6.x image tagged and in your registry so you can redeploy it. Done when the image starts, the Superset CLI reports the expected version, and a test screenshot of a dashboard is produced by Playwright in the container.
Run database migrations and init in staging
In staging only, run superset db upgrade against the restored metadata database copy, then superset init, and capture the full migration output. Review any migration that locks tables or rewrites large columns, and note the expected downtime window before production work starts. Keep the staging database snapshot taken before the migration so the migration can be replayed. Done when both commands exit cleanly, the migration log has no unreviewed errors, and the web application starts against the migrated database.
Verify the access model and subjects
Compare owners, dashboard roles and row level security roles before and after migration, since the notes describe these being replaced by subjects (users, roles or groups) and owners becoming editors. For a sample of dashboards, datasets and RLS rules, confirm that each user and group still sees the same data and can edit what they could edit before. Test the group mappings from your identity provider, and confirm that Swagger UI remains off unless you have set SUPERSET_ENABLE_SWAGGER_UI or FAB_API_SWAGGER_UI. Done when an access matrix signed by the data owner shows no unexplained change in visibility or edit rights.
Test async queries, reports and thumbnails
Exercise the paths the notes say were re-platformed or changed: Global Async Queries, now run as Global Task Framework tasks, scheduled reports and alerts with Playwright screenshots, and dashboard thumbnails. Confirm that the workers and beat processes in staging pick up the tasks, that screenshots render large dashboards completely, and that report recipients receive output in a test mailbox. Compare report output with the 6.x baseline and log any visual difference for the Ant Design 6 change. Done when every scheduled report and thumbnail type produces output in staging and the comparison log has no open blocking item.
Cut over to production with a rollback path
Schedule the change, put Superset into a maintenance state, take a fresh metadata database backup, and then apply the same image and migration steps that passed in staging. Run the smoke checks again in production: login, one dashboard per critical team, one async query, one report send and one thumbnail. If any check fails, redeploy the saved 6.x image and restore the fresh backup, since the migration has changed the schema and rolling back the code alone is not enough. Done when all smoke checks pass, the change record is closed with the final version and migration revision, and the rollback backup is retained for a period your change policy sets.
Which Superset 7.0 breaking changes apply to your install method
If you install Superset from PyPI into a virtual environment, the 7.0 changes reach the interpreter and the packages around it. Confirm the Python version used by every host that runs the web server, the Celery workers and the beat process, because each one needs its own check.
- Python runtime: Superset 7.0 requires Python 3.11 or higher and removes Python 3.10 support. Rebuild the virtual environment on a 3.11 or later interpreter and avoid upgrading packages inside an old environment.
- SQLAlchemy 2.0: SQLAlchemy moves from 1.4 to 2.0, with flask-sqlalchemy 3.1.1. Review pins in your requirements files, database drivers and any custom code that imports Superset's database layer.
- Playwright and Chromium: Selenium support is removed, and Playwright is required for all report and thumbnail screenshots. Install Playwright and its browser in the same environment as the workers that render reports.
- Retired Selenium setup: Remove chromedriver and Selenium settings from systemd units, scripts or environment files that previously drove screenshots.
- Browser host dependencies: The browser needs system libraries and writable space on the worker host. Test a scheduled report from the worker itself, not from a developer workstation.
Before cutover, record python --version on each host, run pip check in the new environment, and confirm the setup steps in the UPDATING.md notes against one generated alert or report from each worker type.
If you run Superset from a container image, the 7.0 changes affect the base image and any Dockerfile that extends the official image. Official images carry the runtime, so your review focuses on what your build adds, removes or pins on top of it.
- Base image Python version: Any custom Dockerfile that starts from an older Python base, or that installs Python 3.10 explicitly, must move to a 3.11 or later base before the build succeeds.
- Selenium and chromedriver layers: Remove build steps that install Selenium, chromedriver or Chromium packages for screenshots, and add the Playwright setup for report and thumbnail rendering.
- Image variant selection: Check which official image variant and tag your pipeline pulls for 7.0, and confirm whether the browser and translation components are included in that variant before you rebuild.
- Pinned dependencies: Requirements layers that pin SQLAlchemy 1.4 or older flask-sqlalchemy versions must be updated to the SQLAlchemy 2.0 line with flask-sqlalchemy 3.1.1.
- Custom frontend assets: Custom CSS and theme overrides that target Ant Design class names need testing, because the frontend builds against Ant Design 6 with renamed internal CSS classes.
Before promoting an image, run the build from a clean cache, start the web and worker containers from the new image, and confirm that a report renders in the worker container. Check the image tag and browser setup in the UPDATING.md notes before you tag the release for deployment.
For Kubernetes, the deployment tool is the first decision. The 6.1.0 documentation describes installs with the official Helm chart. The current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. Confirm which path your cluster uses before you plan the 7.0 change.
- Helm chart status: Teams on the Helm chart should plan a move to the operator path, and should record the chart version, values files and the rendered manifests that are live today.
- Operator maturity: The operator is built with the Go Operator SDK and is in alpha, with a v1alpha1 API. Its custom resource schemas may change between releases, so pin the operator version and review its release notes for every upgrade.
- Configuration translation: Values from the Helm chart do not carry over automatically to operator custom resources. Map each setting, including the Playwright browser workers, the Celery workers and the secret key, to the operator schema.
- Upgrade order: Upgrade the operator, the custom resource schemas and Superset itself in a staging namespace first, then compare the rendered resources against production.
- Runtime changes: Python 3.11, SQLAlchemy 2.0 and Playwright requirements apply to the images the cluster pulls, so the image checks from the container tab still apply.
Before cutover, export the current resources, render the new manifests in staging and confirm that scheduled reports and async queries complete. Review the Kubernetes installation documentation and the operator documentation for the current deployment path.
Testing and rollback for the Apache Superset upgrade when a migration fails
Write the go or no-go rules and the rollback decision before the cutover window opens, because a migration can fail partway through and leave the metadata database in a state that is neither the old nor the new schema. Test in staging against a restored copy of production metadata, not an empty database. Cover each object type that the 7.0 changes touch: dashboards and charts, where owners become editors and dashboard roles and row level security roles are replaced by subjects; alerts, reports and thumbnails, which now depend on Playwright and Chromium because Selenium support is removed; and async queries, which now run as Global Task Framework tasks. A failed check on any of these is a no-go unless the owner of that area signs off a documented exception.
For each check, record the expected result before running it. Confirm that every dashboard opens with its intended viewers and editors, that row level security still filters data for a sample of users from each role, that a scheduled report and an alert both send with a correct screenshot, that thumbnails render, and that a long-running query returns through the task path. Also confirm that Swagger UI is off unless you have set SUPERSET_ENABLE_SWAGGER_UI or FAB_API_SWAGGER_UI on purpose, and that any API client you rely on still works. Check the current release notes for the release candidate you test against, since 7.0 is still a pre-release and the UPDATING.md notes may change before general availability.
The rollback path needs four parts. Stop the web servers and workers so nothing writes to the metadata database, restore the backup you took immediately before the migration, and redeploy the prior image with its prior configuration, including the same SECRET_KEY. Then confirm that reports and schedules resume, that the worker and beat processes reconnect, and that users can sign in. Practice this sequence in staging and time it, because the restore duration is driven by your database size and is something to measure yourself, not assume. Name the person who authorizes rollback, the criteria that trigger it, and the point after which rollback is no longer clean because users have written new content. Keep the upgrade guide steps for backing up and running superset db upgrade in the runbook next to these decisions.
What makes the Apache Superset upgrade take longer
This table lists the inventory items that change how long the 7.0 upgrade takes and how much testing it needs. Count each driver in your own environment before you ask a partner or your own team for a plan, because the depth of each item matters as much as the count.
| Driver | Why it matters | How it moves effort |
|---|---|---|
| Custom visualization plugins | Plugins built on Ant Design 5 or older form data field names must be checked against Ant Design 6 and renamed internal CSS classes. | Rises with the number of plugins and with how deeply each one overrides Superset components or styles |
| Owners and RLS rules | Owners, dashboard roles and RLS roles become subjects (users, roles or groups), with owners becoming editors, which changes metadata and API behavior. | Rises with the count of dashboards, charts and RLS rules that must be reviewed and converted to subjects |
| Reports and dashboards using screenshots | Selenium support is removed, so every scheduled report and thumbnail needs Playwright output checked against the old result. | Rises with the number of scheduled reports, alerts and dashboards whose screenshots are compared |
| Metadata database size and migration risk | The superset db upgrade step runs schema changes on the metadata database, so large tables and a required backup window extend the plan. | Rises with database size, row counts in affected tables and the length of the approved downtime window |
| Custom Docker and base images | Images that install Chromium, Selenium or pinned Python 3.10 packages need rebuilding for Python 3.11 and Playwright. | Rises with the number of custom image builds, registries and deployment pipelines that reference them |
| SSO and group-to-role mappings | Group mappings in AUTH_ROLES_MAPPING tie login to roles, and role-based access depends on subject changes. | Rises with the number of identity providers, LDAP or OAuth groups and mapped roles that must be retested |
| Environments to test | Each environment (development, staging, production, and any disaster recovery copy) needs its own upgrade run and verification. | Rises with the number of environments and with how many of them share a metadata database or cache |
What replacing owners with subjects means for your access model
The breaking change in Superset 7.0 is that ownership and access rules stop pointing at a single user. Per the UPDATING notes, dashboard owners, dashboard roles and row level security (RLS) roles are replaced by subjects, which are records that point to users, roles or groups. Existing owners become editors, so a dashboard that one person built may now be editable by a set of subjects you never reviewed. Treat this as an access model change, not a cosmetic metadata migration, because any rule that previously named a person now resolves through a subject.
Before the staging upgrade, build an inventory from the metadata database. List every dashboard with its owners and dashboard roles, and every RLS rule with the roles and tables it applies to. Record which rules depend on a group from LDAP or OAuth through AUTH_ROLES_MAPPING, because a group that maps to a Superset role will need to resolve to the same subject after the change. Also identify API clients, scripts and embedded integrations that read or write owners, dashboard roles or RLS roles, since their request and response shapes may change. Confirm the exact field and API effects in the final release notes and with each integration owner before you schedule the change.
In staging, test access from the outside in. Sign in as a representative user from each role and group, then check that each dashboard opens with the same permissions as before, that editors can change only what they should, and that RLS filters return the same rows for the same query. Check that users who lost ownership through the change still see the content they need through a role or group subject. Repeat the checks for guest or embedded access if you use it. Keep the results with the change record, since an auditor testing access control will ask how you verified that effective permissions did not widen.
Questions teams ask before the Apache Superset upgrade
What does the Apache Superset 6.x to 7.0 upgrade cost?
The cost depends on the scope agreed in writing, not on a standard package. The main drivers are how many dashboards, charts, reports and custom plugins your instance holds, whether you use alerts and reports with Playwright screenshots, how many custom visualization plugins or Ant Design based customizations need rework, the size of the metadata database that must be backed up and migrated, and how many environments you need to test in. Your cost is split between internal staff time for access, data and access-model decisions and any external work you buy. Recurring costs are the staging environment, worker infrastructure and any retainer for later patches. Ask any quote to separate one-time migration work from ongoing support, and to list which upgrade items are included and which are excluded.
How long will the Superset 7.0 upgrade take?
No duration is given here because the time depends on a scoped plan, and a figure without one would not be useful. The variables are the number of dashboards and owners affected by the move from owners to subjects, the number of custom plugins, the size of the metadata database, how many reports depend on Playwright, and how quickly your team can review staging results. The 7.0 line is still in release candidate form, with 7.0.0rc2 listed as a pre-release on October 16, 2026, so the final breaking changes may still shift. Ask for a timeline only after an inventory of your instance and a written scope exist.
What do we need to provide for the upgrade?
The work needs several things from your side before it starts:
- A staging environment that mirrors production, including the metadata database, caching layer and worker components
- Administrative access to the current Superset instance, its configuration and the container or host it runs on
- A recent, tested backup of the metadata database, following the steps in the upgrading documentation
- Named owners for data access decisions, dashboard ownership and row level security rules, since owners are replaced by subjects in 7.0
- Test users and a sign-off process for dashboards and reports
Confirm these owners early. Most delays come from access-model decisions that nobody has been assigned to make.
Can our internal team upgrade Superset to 7.0 by itself?
Yes, if your team has the skills and time, and the work is well scoped. The project's upgrade guidance covers backing up the metadata database, running superset db upgrade and superset init, testing in staging and checking UPDATING.md for breaking changes. The harder parts are the Python 3.11 minimum, the SQLAlchemy 2.0 move, the Playwright requirement for screenshots, the Ant Design 6 changes in any custom frontend and the rework of ownership into subjects. Teams without recent Superset or Python upgrade experience usually benefit from an outside review of the plan, even if they run the upgrade themselves.
Should we wait for the final Superset 7.0 release before planning?
Plan now, but do not finalize the production cutover until the final release is published. The 6.1.0 release was published on PyPI on May 13, 2026, and the 7.0 release candidate is available for testing. You can start the inventory, check custom plugins, confirm your Python 3.11 path and draft the subject mapping while the release candidate is open. Track the release page and UPDATING.md for changes, and retest against the final tag before go-live.
Does the Helm chart or Kubernetes operator change the upgrade work?
Yes, the deployment method changes how you run the upgrade, though not the Superset breaking changes themselves. The Superset 6.1.0 documentation describes installs with the official Helm chart, while the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. The operator is in alpha with a v1alpha1 API whose schemas may change between releases, so pin versions and test custom resource changes in staging. If you run Helm today, confirm whether you need to move to the operator as part of this upgrade or keep the chart for a defined period.
What is the first step to find out how big our upgrade is?
Start with an inventory of what your instance holds and how it is configured. List the Superset version and Python runtime, the metadata database and its version, the caching and worker setup, every dashboard and report that uses owners, dashboard roles or row level security, custom visualization plugins, and whether alerts depend on Selenium or Playwright. Compare that list against UPDATING.md for each breaking change. The result shows which items are routine and which need design decisions, and it gives you the information a fixed-scope quote requires.
How DeployOpen scopes and delivers the Superset upgrade
DeployOpen approaches the move from Superset 6.x to 7.0 as a written, fixed-scope engagement inside your own infrastructure. We start by inventorying what your deployment depends on, then build and test the upgrade in staging before anything changes in production.
How we scope
- Inventory the Python runtime, SQLAlchemy usage, custom plugins and Docker images that the 7.0 breaking changes touch
- Map which dashboards, reports and thumbnails rely on Selenium-based screenshots that must move to Playwright
- Agree in writing which owner-to-editor and subject-based access changes are in scope, and what is excluded
How we build
- Prepare a staging environment that mirrors production metadata, worker and caching components before any upgrade step runs
- Back up the metadata database, then run the upgrade commands from the Superset upgrade documentation in a documented order
- Test dashboards, alerts, reports, async queries and access rules against a written checklist, and log every deviation found
How we hand over
- Deliver a runbook covering the staging results, the production cutover steps and the rollback path if a migration fails
- Document the configuration changes made, including any Swagger UI, secret key or access setting that differs from 6.x defaults
- Walk your platform and security teams through the handover so they can operate the upgraded instance without us
How we support
- Confirm with your team the post-upgrade monitoring window and which issues are covered by the fixed-scope agreement
- Offer ongoing Superset support, upgrades and continuous testing as a retainer if you want DeployOpen to stay on the platform
- Re-test custom visualization plugins and reports when later Superset releases change their dependencies
