Migrate from Redash to Apache Superset: what the move involves
Superset is a rebuild of your queries, charts and dashboards, not a file conversion. A Redash saved query becomes SQL Lab work or a virtual dataset in Superset, each Redash visualization is recreated as a Superset chart, and each dashboard is laid out again. The effort depends mainly on how many queries, dashboards and alerts you run, and on how your access model maps to Superset roles and row level security. Start by inventorying those three counts and the groups that can see each dashboard, because those numbers, not the tool choice, set the size of the project. Ask any partner to base its quote on that inventory.
The licenses and release history shape the decision more than the feature list does. Redash is published under the BSD-2-Clause license, and Superset is Apache-2.0 licensed with no paid edition, so neither move involves a license purchase. Redash's release history shows a long gap, with v10.1.0 in November 2021 followed by v25.1.0 on January 8, 2025, and later releases including v26.9.0 on September 24, 2026, which fixed 13 security advisories. Read that as a reason to check your current Redash version, its open advisories and your patch cadence before you plan the move, not as evidence about the project's future. Confirm the current status with the Redash releases page before you decide.
Plan the project around the parts that do not transfer automatically. Redash data source connections, alerts and user access must each be redesigned for Superset, including the database connection settings, the alert and report setup that relies on Superset's caching layer and Celery workers, and the roles that replace Redash groups. Keep Redash running in parallel until each dashboard has been rebuilt, checked against the same numbers and signed off by its owners. Superset 6.1.0 was released on May 13, 2026, and 7.0.0 release candidates appeared in October 2026, so confirm which version you will deploy and whether a later stable release is available before you fix the build plan.
Which Redash capabilities map to Superset and which need rebuilding
This table compares each Redash capability with its closest Superset counterpart and marks whether it transfers, needs reconfiguration or must be rebuilt. Use it to scope the migration work before you export anything. Treat every alert and API behavior as unconfirmed until you test it in your own environment.
| Redash capability | Superset equivalent | Migration effort |
|---|---|---|
| Query editor with schema browser and autocomplete | SQL Lab with schema browser and SQL IDE | Equivalent exists. Confirm autocomplete behavior for your database driver. |
| Saved queries | Saved queries in SQL Lab, promoted to virtual datasets where charts need them | Rewrite by hand. Redash query exports do not map to Superset objects directly. |
| Query parameters | Jinja templating and filters on virtual datasets | Rebuild. Parameter syntax and defaults differ, so test each query. |
| Data source connections | Database connections in Superset, with passwords set per connection | Recreate connections and credentials. Confirm driver support for each source. |
| Visualizations | Charts built in the no-code chart builder or from SQL Lab results | Rebuild. Chart types and options are not carried over from Redash. |
| Dashboards | Dashboards composed of Superset charts, with filters and native layout | Rebuild layout and filters. Confirm how each filter binds to datasets. |
| Scheduled refreshes | Cached results and dashboard refresh settings, with Celery workers for async work | Reconfigure. Confirm caching and worker setup before relying on refresh timing. |
| Alerts when data changes | Alerts and reports, which require the caching layer and worker components | Rewrite. Redash alert conditions must be re-expressed and tested in Superset. |
| REST API covering UI functions | Superset REST API with its own endpoints and authentication | Rewrite client scripts. Confirm each endpoint and token method in your version. |
| User roles and access | Flask-AppBuilder roles and permissions, with row level security on datasets | Redesign. Redash group permissions do not map one to one onto Superset roles. |
Documented paths for moving queries, dashboards and connections
Redash and Superset do not share a migration format, so the work splits into several separate paths: rebuilding queries, moving Superset assets between instances, configuring connections, and automating the setup. No documented Redash-to-Superset importer was supplied for this page, so confirm its existence for your target version before you plan around one. The cards below cover each documented option and the checks that matter for each.
Rebuilding Redash queries in SQL Lab
Each saved Redash query becomes a query you run in SQL Lab, and the SQL text usually carries over with changes to parameters, Jinja templating and dialect differences. Once a query works, you can save it as a virtual dataset so charts and dashboards read from one governed definition. Check that each query runs under the Superset database connection and service account you intend to use, and record which Redash queries depended on parameters or scheduled refreshes that need a new home.
Virtual datasets as the replacement layer
In Redash, a query often doubles as the chart source and the dashboard source. In Superset, a virtual dataset plays that role, so charts reference a named dataset rather than a copied query. Decide which queries become shared datasets, which stay as one-off SQL Lab work, and who owns each dataset. Confirm how your Superset version handles dataset metadata, columns and metrics before you rebuild charts that depend on them.
ZIP export and import between Superset instances
Superset can export dashboards, charts and datasets as ZIP archives and import them into another instance, which suits moving content from a staging Superset to production. This path only applies once Superset already holds the content, so it does not move anything out of Redash. Review how the import treats existing UUIDs, overwrites and database connection passwords, and test the import in a non-production instance before you rely on it.
Manual database connection setup
Redash data sources must be recreated as Superset database connections, and Superset expects you to supply the driver, host, database name and credentials yourself. Use a dedicated read-only account per connection, store passwords through your secrets process, and test each connection with the same queries your Redash users run. Keep a list mapping each Redash data source to its Superset connection, because dataset and chart references depend on it.
Superset REST API for automation
The Superset REST API can script repeatable steps such as creating databases, datasets and dashboards, which reduces manual rebuilding when you have many objects. Scripts still need the rebuilt query logic and a verified mapping from Redash IDs to Superset objects. Confirm which endpoints your Superset version exposes, how authentication works for service accounts, and whether the API covers every object type you need before you write scripts against it.
Confirming importer availability first
Before you plan around any automated Redash import, check the Superset documentation and release notes for your target version to see whether a documented importer exists. If none exists, treat every migration step as manual or scripted work and budget review time accordingly. Ask any partner to state in writing which steps they will perform by hand, which by script, and which depend on a tool you have not verified.
What a production Superset needs before any dashboard moves
Before any Redash query or dashboard is recreated, the target Superset must be a production-grade installation, because several parts of Redash's functionality depend on components that a quick-start Superset does not run. Start with the SECRET_KEY: Superset requires a user-specified SECRET_KEY to start, and that key later protects the encrypted database connection passwords you will re-enter during migration. Decide who holds it, where it is stored and how it will be rotated (using PREVIOUS_SECRET_KEY) before anything is imported, because losing or changing it after connections are saved can make them unusable.
Choose the metadata database next. Superset's architecture documentation tests PostgreSQL and MySQL for this role, and the SQLite default used by Quickstart and PyPI installs and the Docker Compose PostgreSQL container are not recommended for production. Check the configuration documentation for the supported versions (PostgreSQL 10 to 17 and MySQL 5.7 and 8.x) and confirm your managed service's version falls inside that range. Unlike Redash, where alerts and scheduled refreshes sit on Redis and background workers you already plan for, Superset expects the caching layer and Celery worker and beat processes for alerts, reports, async queries and dashboard thumbnails, so budget for Redis and Celery as well.
Pin the release. Superset 6.1.0 was published on May 13, 2026 according to PyPI, while 7.0.0rc2 is only a pre-release on the GitHub releases page, so production targets should be a released version and not a release candidate. Confirm the exact version your team will run, read its upgrade notes in the project's UPDATING.md, and rehearse the backup and superset db upgrade steps in staging first. Agree the cutover window and the rollback plan for the Redash side as well, since Redash will keep running until the parallel-run period ends.
How the Redash to Superset cutover runs in phases
The sequence moves Redash content and users onto Superset in verified stages, so every query, dashboard and alert has a checked replacement before Redash is switched off. Each phase closes with a written output the project owner can sign off.
Inventory queries, sources, dashboards and alerts
Export a full list of Redash data sources, saved queries, dashboards, alerts, scheduled refreshes and users, including who owns each item and who receives each alert. Record which items are actively used, using Redash query and dashboard metadata and your own access logs, and mark the rest as candidates for retirement. The step is done when the inventory has an owner, a business purpose and a disposition (migrate, rebuild, or retire) for every row, and the data owners have signed it off.
Stand up a production-grade Superset in staging
Deploy Superset in a staging environment that matches the planned production design, with a PostgreSQL or MySQL metadata database rather than SQLite, a SECRET_KEY set before first start, and the caching and worker components your alerts and reports need. Confirm the supported metadata database versions in the configuration documentation before you choose them. Connect the same database engines Redash uses, using read-only accounts. The step is done when a test login, a test query and a test alert delivery all succeed in staging.
Rebuild a pilot set of queries and dashboards
Select a small pilot of high-value queries and dashboards that cover each data source type and one alert. Recreate the SQL as SQL Lab queries, define virtual datasets where several charts share logic, and rebuild the visualizations and dashboards in Superset. Record any differences in SQL dialect, time zone handling or aggregation logic. The step is done when the pilot dashboards show the same figures as Redash for the agreed reference period and the differences are documented and accepted by the data owners.
Run Redash and Superset in parallel
Keep Redash running for the migrated scope while business users check the Superset equivalents against it. Agree reconciliation checks beforehand, such as row counts, totals for key metrics, and comparisons of alert trigger conditions, and run them on a fixed schedule. Log every mismatch with its root cause and fix. The step is done when all agreed checks pass across the parallel period, and the data owners confirm the results in writing.
Migrate the remaining assets in waves
Rebuild the rest of the inventory in groups by business area, applying the same pattern used for the pilot. Move alerts only after their Superset equivalents have passed reconciliation, and disable the Redash version when the Superset version starts sending. Map Redash groups to Superset roles and row level security where data access differs by team, reviewing these mappings with the data owners. The step is done when every item in the inventory has a Superset counterpart or a recorded retirement decision.
Cut over users and alert recipients
Move users to Superset by provisioning their accounts, roles and access through your chosen identity method, then communicate the new links and retire bookmarks to Redash. Update alert recipient lists and confirm that each recipient receives the Superset notification through the expected channel. Publish a short guide for users covering where each dashboard now lives. The step is done when the user list matches the inventory and no alert still points to a Redash query.
Decommission Redash after the retention period
Keep Redash in read-only mode for the retention period your organization agrees, and export its queries, dashboards and metadata for records. Then shut down the Redash API server, background worker, Redis and PostgreSQL components, and remove access to its data source credentials. Confirm that the export is restorable before deleting the database. The step is done when the export is verified, Redash services are stopped, and the change is recorded in your asset register.
What drives the cost and duration of a Redash migration
This table lists the factors that move the effort and cost of a Redash to Superset migration, and whether each cost is paid once or recurs. Use it to see which parts of your Redash estate will need the most rebuild, validation and parallel running. Figures and timelines come from a written scope agreed before work starts, so the table names drivers rather than prices.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Saved query count and SQL complexity | Each saved query is moved into SQL Lab or a virtual dataset and re-checked, so long queries with joins, CTEs and vendor-specific functions take more rebuild and testing. | Retire unused queries before the move and group similar queries into shared datasets. |
| Parameterized queries and query-to-query dependencies | Redash parameters and queries that read other query results must be rebuilt as Jinja templating, datasets or semantic logic, which needs design decisions rather than copying. | Inventory dependency chains early and agree which chains are kept as they are versus simplified. |
| Dashboard and visualization count | Each dashboard is rebuilt chart by chart, and filters and layouts often need to be redesigned because Superset organizes them differently. | Consolidate near-duplicate dashboards and limit the chart types you carry over. |
| Alert count and notification channels | Redash alerts on data changes must be recreated as Superset alerts and reports, which depend on the caching layer and Celery workers, and each channel needs configuration and testing. | Keep only alerts someone actively acts on and confirm which notification channels your team uses. |
| Data source count and credential handling | Each Redash data source needs a Superset database connection, its credentials re-entered or rotated, and network paths checked from the new host. | Use a single service account per database with the privileges reporting needs. |
| Identity and group mapping | Users, groups and Redash permissions must map to Superset roles, which is slower when group membership is inconsistent across identity sources. | Clean up group membership in your identity provider before mapping, and confirm the group-to-role rules with owners. |
| Row level security design | Access rules that Redash handled through data source or query permissions may need explicit Superset row level security, which requires design and testing per dataset. | Document which datasets hold sensitive rows and limit RLS to those. |
| Parallel-run length | Running Redash and Superset side by side keeps two environments patched and funded until users sign off, and the length depends on how many teams must validate their reports. | Agree exit criteria for each team in advance so the parallel period has an end date. |
| Business validation capacity | Results must be compared against trusted figures, and the speed of this work depends on how much time domain owners can give, which the team cannot supply on their behalf. | Name validation owners and reserve their time in the written scope before work starts. |
| One-time costs | Rebuilding queries, dashboards, alerts and access, plus validation and setting up the Superset hosting environment, are paid once for the migration. | Ask for each one-time line item separately in the quote so you can see what is rebuilt versus validated. |
| Recurring costs | Hosting the metadata database, cache, workers and web servers, plus patching and upgrades for Superset, continue after cutover and are often paid on a retainer. | Ask for the recurring support scope and upgrade approach in writing, and confirm which items your own team keeps. |
Where Redash migrations to Superset usually go wrong
Most Redash-to-Superset cutovers fail in predictable places: metrics that quietly change meaning, alerts that stop firing, users who lose access, and production runs on defaults meant for trials. Each risk below has a prevention step that ties back to a parallel run and a written procedure, so problems surface before users notice them.
Metric definitions drifting
A Redash query often hides business logic in a WHERE clause, a join or a filter that a dashboard user never sees. When the same figure is rebuilt as a Superset virtual dataset or chart, small differences in null handling, time zones or deduplication can change the number. Before cutover, run the old and new queries side by side for the same date ranges and record every variance. Store the agreed definition in the dataset description so the next editor knows what the number means.
Alerts that stop firing
Redash alerts run inside its own worker processes, so they do not move with the dashboards. In Superset, alerts and reports depend on the caching layer and worker components, and most installations use Redis and Celery for them. If those workers are not running or the recipients are not recreated, alerts fail without an obvious error. Build an inventory of every active Redash alert, then send a test trigger from each Superset equivalent and confirm the notification arrives.
Users losing access
Redash groups and data source permissions do not map one to one onto Superset roles and dataset access. Users who could see a query may land in Superset with no role, or with a role that exposes more data than intended. Map each Redash group to a named Superset role on paper first, then review the result with the data owners. Log in as a sample of users from each group during the parallel run and confirm they see the same dashboards and nothing more.
Database passwords not carried over
Redash stores data source credentials in its own database, and those values do not move into Superset automatically. Connections created without their passwords fail on the first query, often after a dashboard has already been shared. Confirm which credentials are needed, rotate them where policy requires, and enter them through a controlled procedure rather than pasting them into a shared ticket. Test each connection from the Superset metadata database host, not only from a workstation.
Running production on defaults
Quickstart and PyPI installs use SQLite as the metadata database, and the Docker Compose PostgreSQL container is not recommended for production. Teams that move quickly sometimes keep these defaults after cutover. Set up PostgreSQL or MySQL for the metadata database, configure a user-specified SECRET_KEY before first start, and document the backup and restore steps for the metadata database. Confirm the versions you run against the supported range listed in the configuration documentation.
Tracking pre-release components
The Superset release notes list 7.0.0rc2 as a pre-release, and the Kubernetes Operator is in alpha with a v1alpha1 API whose schemas may change. Building a production migration on a release candidate or an alpha component means a later upgrade may require rework. Pin production to a stable release, record the version in your runbook, and read the upgrade guidance and UPDATING.md before each change. Schedule the upgrade in staging first, with the metadata database backed up beforehand.
Questions teams ask before moving from Redash to Superset
What does a Redash to Superset migration cost, and what drives the price?
The cost comes from the work, not from a license, because Apache Superset is Apache-2.0 licensed and has no paid edition. The main components are the inventory of queries, dashboards, alerts and users, the rebuild of each visualization and dashboard in Superset, the connection and permission setup for each data source, the hosting and staffing needed to run Superset, and the parallel run. The biggest drivers are how many saved queries and dashboards you have, how many are still used, how many depend on alerts or scheduled refreshes, and how many data sources you connect. One-time work covers the migration itself, while hosting, patching, upgrades and support recur. When you request a quote, ask for the work broken out by inventory, rebuild, data source setup, alerts, access, testing and cutover, with a clear statement of what the client team provides.
How long does a migration from Redash take?
Duration depends on what you have to move and how long the old and new tools must run side by side. Teams with a short, well-documented list of dashboards and few alerts usually finish faster than teams with hundreds of ad hoc queries whose owners are unknown. The steps that most often set the schedule are the inventory, the decision about which assets to retire, the rebuild of dashboards that business users depend on, the verification that numbers match, and the parallel run period while users compare results. Ask for a timeline that ties each phase to a named deliverable and to the client sign-offs that unlock the next phase, and confirm what happens if a data source needs a new network path or credentials.
Can our own team migrate from Redash to Superset without a partner?
Yes, a capable internal team can do it, provided it has the skills and protected time for the work. The team needs someone who can deploy and operate Superset with a PostgreSQL or MySQL metadata database, Redis and Celery if alerts, async queries or thumbnails are needed, and someone who knows the SQL behind your current queries. Owners of the dashboards and the data sources must also be available to validate results. Teams usually underestimate the operations side: backups, SECRET_KEY handling, upgrades, and access control. A partner is most useful when the internal team has no Superset experience, when the rebuild load competes with other work, or when auditors will review the access model. Decide based on your inventory and your team's current capacity.
Do Redash queries convert to Superset automatically?
No, Redash queries do not convert automatically. Superset does not provide a documented importer for Redash saved queries, visualizations or dashboards, so each one must be rebuilt. The SQL itself usually moves with modest effort: you copy a query into SQL Lab, check that it runs against the same data source, and save it as a virtual dataset when other charts depend on it. Charts and dashboards then need to be rebuilt in Superset's chart builder, and the layout, filters and drill-downs need to be recreated and checked. Parameters, query-level permissions and scheduled refreshes also need manual mapping. Confirm with your Superset vendor or implementation partner how they handle any export format you plan to use before you assume any content can be imported.
Is Apache Superset free to run, and what do we still pay for?
Apache Superset is free to use under the Apache License 2.0 (SPDX: Apache-2.0), and the project has no paid edition. You still pay for the infrastructure and the people who run it. Infrastructure includes compute for the web server, the metadata database, Redis and Celery workers if you use alerts and reports, backups, storage and network access to your data sources. People cost includes platform administration, security patching, upgrades, access reviews, and the analysts who maintain datasets and charts. Plan these as recurring costs, not one-time costs. Also confirm whether you want vendor support or a retainer, since that is a separate contract with its own scope.
What do we need to provide before the migration starts?
The migration needs named owners and an agreed inventory before any rebuild begins. Name one executive sponsor, one project owner on your side, and one owner for each data source and each business area that uses Redash. Each saved query and dashboard should have an owner who confirms whether it is still needed, who should receive it, and what a correct result looks like. You also need read access to the data sources, service accounts with the least privilege needed, network paths from the Superset host to each database, and a staging environment where tests can run. Provide access to your Redash instance so the inventory can be exported and reviewed, and make sure someone can approve the cutover date.
Will alerts and scheduled refreshes move over to Superset?
Alerts and scheduled refreshes need separate planning because they do not move with the queries. Superset's alerts and reports, async queries and dashboard thumbnails depend on the caching layer and worker components, and most installations use Redis and Celery for them. You must recreate each alert condition, recipient list and schedule, then test that notifications arrive and that the data they check is current. Consider which Redash alerts are still used before rebuilding them, and decide who receives notifications after the cutover. Email delivery and any chat integration need configuration on the Superset side. Ask your implementation partner to show how they test alerts in staging.
How do we keep access controls intact after moving from Redash?
Redash users, groups and data source permissions must be redesigned in Superset rather than copied. Superset is built on Flask-AppBuilder, supports OAuth2 providers and LDAP, and can map groups to roles through AUTH_ROLES_MAPPING, so the target design should start from your identity provider's groups. Decide which roles give access to datasets, which need row level security, and which users can export data. Test each role with real accounts in staging before cutover. Auditors will look at who can see which data, so keep a written mapping from old Redash permissions to new Superset roles and record the review.
How DeployOpen scopes the Redash to Superset move
DeployOpen plans and implements self-hosted Apache Superset inside your own cloud accounts, data centers or restricted networks, and the move from Redash is scoped in writing before any work starts. Most engagements of this kind are fixed-scope, so the agreed document fixes which Redash objects are in scope, which data sources need new Superset database connections, which dashboards and alerts must be rebuilt, and what the acceptance checks are. Because Superset and Redash model queries, charts and access differently, the scope should be decided from an inventory rather than from an estimate of how many dashboards exist.
The inventory deliverable lists every saved query, dashboard, alert, scheduled refresh, data source and user group in the Redash instance, with an owner and a disposition for each item: rebuild as a virtual dataset, rebuild as a chart, retire, or hand back to the business owner. The rebuild deliverable covers the Superset objects themselves, including the metadata database, database connections, roles and any alert and report configuration that depends on the caching layer and Celery workers. The validation deliverable compares results from the old and new dashboards for agreed queries, and the handover deliverable covers configuration, runbooks and an operations plan. Ask for each deliverable to be named, dated and tied to an acceptance check in the written scope.
Ongoing support, version upgrades and continuous testing are available as retainers after handover, which suits teams that want Superset kept current against the project's release cadence. Confirm with your own environment team which costs sit outside the scope: database licensing or compute, identity provider changes, mail relay and any Redash data source that cannot be reached from the new network. Those items decide much of the final cost, so list them in the written scope before you compare quotes.
How DeployOpen works on this
DeployOpen plans, builds, documents and supports the move from Redash to Apache Superset inside your own infrastructure, whether that is a cloud account, a data center or an air-gapped network. We start from an inventory of your Redash queries, dashboards, data sources, alerts and users, then agree the scope in writing before any migration work begins.
How we scope
- Inventory saved queries, dashboards, alerts, data source connections and user groups in your existing Redash instance.
- Agree in writing which queries become SQL Lab queries or virtual datasets and which are retired.
- Confirm the target Superset version, metadata database, caching layer and worker components before build starts.
- Engagements are fixed-scope, so deliverables and timelines are settled in the written scope before work starts.
How we build
- Stand up Superset in your environment with a production metadata database instead of the SQLite default.
- Recreate data source connections with credentials held in your own secret handling, not copied from Redash configuration.
- Rebuild priority dashboards and charts, then compare results against Redash output for the same queries and date ranges.
How we hand over
- Document the mapping from each Redash query and dashboard to its Superset dataset, chart or dashboard.
- Provide a cutover runbook covering user access, role assignments, alert recreation and the Redash shutdown order.
- Walk your operations and analytics teams through the running system and the open items that remain after cutover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the migration is complete.
- Support can cover Superset upgrades, which the project documents as requiring a metadata database backup and a staging test first.
- Confirm with us during scoping which post-cutover support tasks belong in a retainer and which fall to your own team.
