Update Apache Superset Without Breaking 2026

Updating Apache Superset without breaking production requires method and discipline. Major versions can introduce breaking changes (drivers, configuration, permission model). This guide proposes a proven procedure in 2026.

1. Why update?

• Security patches (CVE);
• New features;
• Performance improvements;
• Compatibility with recent drivers;
• Support for newer Python versions.

If you want automatic updates without managing this process, TVL Managed Superset applies updates with prior tests on all instances.

2. Recommended cadence

Type	Frequency
Patch (5.0.x)	Monthly, on publication
Minor (5.x → 5.y)	Quarterly, after staging tests
Major (5.x → 6.0)	Half-yearly, after breaking changes review

3. Pre-flight checks

1. Read the official UPDATING.md;
2. List installed drivers (psycopg2, snowflake, BigQuery) and check compatibility;
3. Full Postgres backup (cf. backups);
4. Export critical dashboards in YAML;
5. Check used feature flags.

4. Staging environment procedure

Test on staging first:

1. Clone production Postgres DB to staging;
2. Bump the Superset image (apache/superset:5.0.0 → 5.1.0);
3. helm upgrade or docker compose up -d;
4. Verify the success of the superset-init job applying Alembic migrations;
5. Manually test the 5-10 most-used dashboards;
6. Test authentication (SSO, local login);
7. Test SQL Lab and async queries;
8. Test a scheduled report.

5. Production rollout

If staging is OK:

1. Announce a maintenance window;
2. Full Postgres backup;
3. Helm upgrade in production;
4. Monitor migration logs;
5. Quick smoke test;
6. Post-deployment communication.

This configuration is applied by default on TVL Managed Superset, which follows community best practices.

6. Known breaking changes to watch

Version	Breaking change
3.0	Roles and permissions overhaul
4.0	New UX, metadata migration
5.0	uv venv (psycopg2 driver to reinstall via uv pip), Python 3.10+
5.x	Progressive removal of experimental feature flags

7. Rollback

If upgrade fails:

# Helm rollback
helm rollback superset 1 -n superset

# Or redeploy previous version
helm upgrade superset superset/superset \
  -n superset --version 0.14.0 -f values.yaml

# Restore DB if Alembic migrations were applied
psql ... < backup_pre_upgrade.sql

Alembic migrations are sometimes irreversible. Hence the importance of pre-upgrade backup.

8. Common pitfalls

• Skipping intermediate versions: jumping from 3.x to 5.x can break migrations;
• Obsolete drivers: install the new version before upgrade;
• Experimental feature flags removed without notice;
• Different SECRET_KEY between staging and production: invalid sessions after switchover;
• No freeze period: dashboard changes during upgrade.

9. Continuous automation

With ArgoCD or Flux, patch upgrades can be applied automatically after CI tests:

• Renovate / Dependabot to detect new versions;
• CI testing the new image (smoke tests);
• PR auto-merged if tests pass;
• Progressive deployment (canary).

10. Conclusion

A well-prepared Superset update takes 1-2 hours and goes smoothly. Poorly prepared, it can block an instance for days. The method (staging, backup, smoke tests, rollback ready) is more important than the targeted version.

Want the benefits of Apache Superset without the friction of installation and maintenance? Deploy your instance in 3 clicks with TVL Managed Superset, hosted in Europe (OVHcloud, Roubaix, France), managed updates.

For more: backups, disaster recovery, production checklist.