Every mid-market analytics platform team running Apache Superset in production is staring down the same decision right now: when and how to upgrade to 6.0. This isn’t a routine point-release bump. Superset 6.0 introduces a fundamental shift in how permissions are modeled—moving from the old Flask-AppBuilder role synchronization to a group-based access control system—and it swaps out the default table visualization library for AG Grid. The changes are substantive, and if you skip the prep work, you’ll break dashboards that finance teams, operations leads, and customer-facing embedded analytics depend on.
At PADISO, our platform engineering teams have been running Superset in production for mid-market and private-equity-backed businesses across the United States, Canada, and Australia. We’ve already taken multiple D23.io deployments through the 6.0 upgrade on AWS, Azure, and Google Cloud, and we’ve catalogued the exact pain points: the security group model migration that can lock users out of their own charts, the AG Grid table replacement that silently alters column behavior, configuration keys that disappeared without a deprecation warning, and the rollback procedure that most changelogs don’t cover. This guide is the operator’s playbook we use internally—and it feeds directly into our fixed-fee Superset engagement offer for teams that want the upgrade handled without the operational risk.
Whether your Superset instance lives in platform development in New York, runs inside a Toronto financial services stack, or powers embedded analytics for a Sydney scale-up, the architectural truths are the same. Here’s how to navigate them.
Table of Contents
- Understanding the 6.0 Security Group Model
- AG Grid Table Migration: What Breaks and How to Fix It
- Config Breakages and Deprecations
- The Rollback Plan: Safe Return to 5.x
- Testing Before You Upgrade: A Realistic Staging Workflow
- AI Integration and the Superset 6.0 Surface Area
- PADISO’s Fixed-Fee Superset Upgrade Engagement
- Summary and Next Steps
Understanding the 6.0 Security Group Model
The single most disruptive change in Superset 6.0 is the migration from Flask-AppBuilder’s role-centric permission system to a group-based access control model. Under the old regime, you defined roles (e.g., Gamma, Alpha, admin) and assigned permissions to those roles. Upgrading to 6.0 forces a re-synchronization where roles are mapped to groups, and the synchronization behavior can silently drop custom permissions that your team has layered on top of the default roles over years of operation.
According to the official Apache Superset security documentation, the new model treats groups as the primary authorization container, with roles now serving as collections of permissions that get attached to groups. This flips the inheritance chain and means that any direct role-to-user assignments you made outside the FAB synchronization script will not survive the upgrade unless you explicitly migrate them beforehand.
We’ve seen two common failure patterns in production. First, a mid-market logistics company running Superset on AWS lost dashboard access for 40 internal users because their custom report_viewer role—created three years ago by a contractor—wasn’t picked up by the automatic migration. Second, a private-equity-backed retail analytics platform discovered that the sql_lab permission granted to a subset of Gamma users vanished, breaking their ad-hoc query workflow. Both incidents trace back to the same root cause: the upgrade’s role synchronization logic only migrates roles that match FAB’s known naming conventions.
Pre-Migration Audit
Before you touch the upgrade button, run a full permissions audit. Export your current role and user mappings using the Superset CLI:
superset fab list-roles
superset fab list-users --role <role_name>Compare this output against the default roles shipped with your current Superset version. Any custom role that doesn’t map cleanly to a standard Alpha, Gamma, granter, or sql_lab role needs a manual migration plan. We recommend creating a new group in the 6.0 target environment and assigning the equivalent permissions before you cut over.
For teams that must maintain audit-readiness—especially those pursuing SOC 2 or ISO 27001 certification—the security model change introduces a compliance surface area you can’t ignore. Our Security Audit practice uses Vanta to map permission boundaries and prove that access controls remain consistent across the upgrade. If your auditor expects a stable RBAC model, you need evidence that the group migration preserved every access control you attested to. We’ve helped platform development in Washington, D.C. clients and Canberra government teams lock this down without delaying their compliance timelines.
The Group Sync Script
Superset 6.0 includes a management command to synchronize roles to groups:
superset sync-roles-to-groupsRun this in a staging environment first. The command reads your existing roles, creates corresponding groups, and assigns permissions. However, it assumes that all roles should become groups with the same name. If you have naming collisions or roles that shouldn’t be elevated to group status, you’ll need to clean up the mapping manually via the Superset UI or the REST API.
We’ve found that the safest path is to run the sync script, immediately export the resulting group list, and then compare it against a pre-upgrade role export. Any discrepancies need to be resolved before you promote the instance to production. This is not a step to automate blindly—it requires operator judgment.
AG Grid Table Migration: What Breaks and How to Fix It
Superset 6.0 replaces the legacy table visualization with AG Grid, a more powerful and performant grid component. The change is welcome—AG Grid handles large datasets better and supports features like column pinning and in-cell editing—but it is not a drop-in replacement. The migration alters default rendering behavior, and dashboards that relied on the old table’s quirks will look wrong or fail to load entirely.
The 6.0.0 changelog lists the breaking changes: column width calculations are now dynamic by default, the allow_render_html flag is deprecated, and the page_length parameter maps differently to AG Grid’s pagination model. If your dashboards contain tables with custom CSS injected via the table_timestamp_format or conditional_formatting options, those will not transfer automatically.
Column Width and Alignment
AG Grid uses a different algorithm for computing column widths. In the old table, you could set a fixed pixel width and count on it; AG Grid defaults to autoSizeColumns which recalculates based on content. For dashboards with carefully aligned columns—think financial reports where the “QoQ Change” column must sit exactly at the right edge—this causes visual breakage.
Fix it by explicitly setting column definitions in the chart’s JSON metadata. You can access this via the Explore view, switch to the JSON tab, and add a column_config dict:
"column_config": {
"revenue": {
"width": 120,
"cellRenderer": "agAnimateShowChangeCellRenderer"
}
}We’ve had to touch hundreds of charts during client upgrades. Our platform development in Melbourne team built a script that scans chart metadata for tables and flags those without explicit column configs, which cuts the manual review time significantly.
HTML Rendering and Security
The old table allowed allow_render_html to inject raw HTML into cells—a feature often used for status badges or clickable links. AG Grid disables this by default as a security hardening measure. If your dashboards depend on HTML rendering, you must migrate those to AG Grid’s cell renderer components. The fastest path is to use the built-in agAnimateShowChangeCellRenderer for numeric deltas and custom cell renderers for more complex HTML. This requires JavaScript development, which is why we recommend budgeting a sprint for the table migration alone.
Preset’s release overview highlights the migration path and notes that AG Grid is now the default for all new charts, but existing charts are automatically upgraded during the migration. That auto-upgrade is what causes the silent breakage—it doesn’t warn you that your HTML-based conditional formatting just disappeared.
Pagination and Performance
AG Grid’s virtual scrolling is a net positive for performance, but the page_length parameter no longer controls the number of rows fetched in one batch. Instead, AG Grid fetches data in chunks based on viewport size. If you had tuned page_length to manage memory on large datasets, you’ll need to adjust the new cacheBlockSize property in the chart configuration. This is especially relevant for embedded Superset deployments where browser memory is constrained—a common scenario in our platform development across Canada work.
Config Breakages and Deprecations
Beyond the security model and table migration, Superset 6.0 removes or renames several configuration keys that production operators depend on. The changelog captures the high-level items, but we’ve encountered additional breakages that only surface under specific deployment topologies—particularly Kubernetes environments with custom superset_config.py overrides.
Removed Feature Flags
ENABLE_TEMPLATE_PROCESSING has been removed. If you used Jinja templating in SQL Lab queries, you now need to migrate to the new ENABLE_ADVANCED_DATA_TYPES flag and rewrite templates to use the updated syntax. This broke a client’s entire set of dynamic dashboards that pulled date ranges from template variables. The fix required a day of SQL refactoring.
DASHBOARD_NATIVE_FILTERS is no longer a feature flag; native filters are always on. If your config explicitly set this to False to fall back to the legacy filter box, that override is now ignored, and any dashboards that relied on the legacy filter box behavior will need to be rebuilt with native filters. This is a significant effort for teams with large dashboard inventories.
Database Connection URI Changes
The SQLALCHEMY_DATABASE_URI format now enforces stricter validation. We’ve seen instances where a trailing slash or an extra query parameter that worked fine in 5.x causes Superset 6.0 to refuse to start. The error message is opaque—something like “Invalid connection string”—and it doesn’t tell you which part of the URI is offending. Our platform development in the United States team has a pre-flight check that parses the URI against the new validation regex and flags issues before the upgrade.
Kubernetes-Specific Breakages
If you run Superset on Kubernetes with a custom superset_config.py mounted via ConfigMap, watch out for changes to the Celery beat schedule configuration. The CELERYBEAT_SCHEDULE key has been renamed to CELERY_BEAT_SCHEDULE in some deployment manifests, and the old key is silently ignored, causing your scheduled reports and alerts to stop firing. We’ve seen this hit production within 24 hours of an upgrade because the failure is silent—no errors in the logs until someone notices the Monday morning report didn’t arrive.
You can track ongoing updates and community-reported issues via Releasebot, which aggregates changes across releases. We use it as a secondary check alongside the official changelog.
The Rollback Plan: Safe Return to 5.x
No upgrade guide is complete without a tested rollback procedure. Superset 6.0 modifies the metadata database schema, which means a simple binary rollback will leave you with a schema mismatch and a broken instance. You must plan for database restoration before you upgrade.
Database Backup and Schema Snapshot
Take a full database dump immediately before the upgrade. For PostgreSQL-backed deployments, use:
pg_dump -h $SUPERSET_DB_HOST -U $SUPERSET_DB_USER -d $SUPERSET_DB_NAME > superset_pre_6.0.sqlAlso capture the current Alembic migration head so you know exactly which schema version you’re on:
superset db currentStore both artifacts in a secure location outside the cluster. If you’re on AWS RDS, take a manual snapshot as an additional safety net.
The Rollback Sequence
If you need to roll back:
- Stop all Superset pods or processes.
- Restore the database from the pre-upgrade dump.
- Deploy the previous Superset version (5.x) with the old configuration.
- Run
superset db upgradeto ensure the schema matches the old code. - Verify that dashboards and permissions are intact.
The entire sequence should take under 30 minutes if you’ve practiced it. We recommend running a rollback drill in staging before the production upgrade. Our CTO as a Service engagements always include a documented rollback runbook because we’ve seen too many teams skip this step and then scramble when something breaks.
Stateful Dashboard Data
If your users created new dashboards or modified existing ones between the upgrade and the rollback, those changes will be lost when you restore the database. Communicate this clearly to stakeholders before you begin the rollback. For mission-critical dashboards, consider exporting them as JSON via the Superset API before rolling back, then re-importing them after the rollback completes.
Testing Before You Upgrade: A Realistic Staging Workflow
Most teams have a staging environment, but few staging environments accurately mirror production’s permission model, dashboard inventory, and traffic patterns. A realistic test requires cloning the production metadata database and running the upgrade against it.
Database Cloning
Create an anonymized clone of your production metadata database. You can use a tool like pg_dump with the --exclude-table-data option for sensitive tables, then restore into a staging database. The goal is to have the exact same roles, dashboards, charts, and datasource connections—just with user PII stripped if necessary.
Automated Dashboard Validation
After upgrading the staging instance, run a script that loads every dashboard URL and checks for HTTP 200 responses and the presence of expected chart elements. We use a headless Chromium script that takes screenshots and diffs them against pre-upgrade baselines. This catches visual regressions that linting tools miss. Our platform development in Ottawa team open-sourced a lightweight version of this validator for Superset dashboards.
Load Testing the AG Grid Migration
AG Grid’s performance characteristics differ from the old table. Run a load test that simulates concurrent users opening dashboards with large tables. We’ve seen cases where AG Grid’s virtual scrolling reduces server-side load but increases client-side memory usage, causing browser crashes on older hardware. If your internal users are on thin clients or VDI, this matters.
AI Integration and the Superset 6.0 Surface Area
Many of our clients are embedding Superset into AI-augmented workflows—using large language models to generate SQL queries, summarize dashboards, or trigger alerts based on anomaly detection. The upgrade to 6.0 changes the API surface slightly, and if you’ve built integrations against the Superset REST API, you need to regression-test them.
For teams using Claude Opus 5 or Claude Sonnet 5 to generate SQL Lab queries via the API, the new security group model affects how API tokens map to permissions. A token that previously had Gamma-level access might now resolve to a group with fewer permissions if the migration didn’t map correctly. We’ve built a test harness that runs a suite of API calls immediately after upgrade to catch these regressions before they impact production.
If you’re exploring AI-driven dashboard generation—using Claude Fable 5 to create chart configurations from natural language descriptions—the AG Grid table’s new JSON schema means your prompt engineering needs an update. The old table schema is no longer valid, and the model will produce configurations that fail to render unless you provide it with the updated schema in the system prompt. Our AI & Agents Automation practice helps clients retool these integrations, ensuring that the move to 6.0 doesn’t silently degrade AI-powered features.
PADISO’s Fixed-Fee Superset Upgrade Engagement
We’ve seen enough Superset 6.0 upgrades to know that the work breaks down into a predictable set of tasks: pre-migration audit, security group mapping, AG Grid chart remediation, config validation, staging test, production cutover, and rollback drill. That’s why we offer a fixed-fee engagement that covers the entire upgrade for mid-market teams running Superset on AWS, Azure, or Google Cloud.
The engagement includes:
- A full permissions audit and group migration plan.
- Automated scanning of all dashboards for AG Grid compatibility issues.
- Remediation of up to 50 charts with custom column configs or HTML rendering replacements.
- Kubernetes manifest updates for Celery beat schedule and other config breakages.
- A staging environment test with dashboard validation.
- A production cutover runbook with a defined rollback window.
- Post-upgrade monitoring for 72 hours.
This isn’t a consulting engagement where we bill by the hour and hope for the best. It’s a fixed-price, fixed-scope upgrade that we’ve delivered for platform development in Australia clients, New Zealand teams, and private-equity portfolio companies across the US. You can read about our approach in our case studies and explore related deep-dives on our blog.
If you’re staring down the 6.0 upgrade and don’t have the in-house bandwidth to do it safely, reach out to our team and we’ll walk you through the fixed-fee scope and timeline.
Summary and Next Steps
Apache Superset 6.0 is a meaningful release that closes long-standing security gaps and modernizes the visualization layer. The cost of upgrading is real, but the risk of staying on an outdated version—with an unsupported permission model and a deprecated table component—is higher. The key is to treat the upgrade as a structured project, not a routine operation.
Your next steps:
- Export your current roles and dashboards. Map every custom permission to the new group model.
- Clone your metadata database into a staging environment and run the upgrade.
- Audit every dashboard that contains a table chart. Fix column configs and HTML rendering.
- Validate your
superset_config.pyagainst the 6.0 changelog. Remove deprecated feature flags. - Practice the rollback procedure at least once.
- Cut over during a low-traffic window with database backups in hand.
If you’d rather not shoulder the operational burden, PADISO’s fixed-fee Superset upgrade engagement exists precisely for this moment. We’ve done it across platform development in Toronto, Melbourne, and Washington, D.C., and we can have your instance upgraded and validated within two weeks.
Superset 6.0 is the foundation for the next three years of embedded analytics. Get the upgrade right, and you’ll be positioned to ship dashboards faster, with better security, and with a table component that actually handles the data volumes your business generates.
flowchart TD
A[Start Upgrade Planning] --> B[Export Roles & Dashboards]
B --> C{Audit Custom Permissions}
C -->|Custom Roles Found| D[Map to Groups Manually]
C -->|No Custom Roles| E[Proceed with Auto-Sync]
D --> E
E --> F[Clone Metadata DB to Staging]
F --> G[Run 6.0 Upgrade in Staging]
G --> H[Validate Dashboards & Tables]
H --> I[Fix AG Grid Column Configs]
I --> J[Validate Config Breakages]
J --> K[Run Rollback Drill]
K --> L[Schedule Production Upgrade]
L --> M[Backup Production DB]
M --> N[Upgrade Production]
N --> O[Monitor 72 Hours]
O --> P[Upgrade Complete]
N -->|Failure| Q[Execute Rollback Plan]
Q --> R[Restore DB & Downgrade]
R --> S[Post-Mortem & Retry]