Migrate from Amazon QuickSight to Apache Superset

Migrate from Amazon QuickSight to Apache Superset: what moves and what does not

Dashboards, charts and the logic behind them can be rebuilt in Apache Superset, but the data, SPICE caches and reader sessions do not transfer. Your QuickSight asset bundle export gives you a specification to rebuild from, while the rows themselves stay in your warehouse or lake and must be reached by Superset through its own database connection. Teams usually arrive here because a renewal, per-user or per-session pricing, a data residency requirement or lock-in has made the current setup harder to justify, and the question is which parts of the estate can be moved without losing trust in the numbers.

The move is normally run by a platform or data team with a named BI owner who signs off on metric definitions. The BI owner decides which dashboards are still used, which calculated fields and filters encode business rules, and who approves the result. The platform team handles the Superset deployment, its metadata database, the caching layer and any Celery workers that alerts, reports or async queries need. Expect the effort to concentrate in three places: reconnecting each dataset to the SQL source, reproducing calculated fields and row-level access rules in Superset's own model, and reconciling figures against QuickSight output before users cut over. Effort rises with the number of SPICE datasets that depended on import schedules and with the number of dashboards whose logic lives only in QuickSight calculated fields.

Plan for the risks that are easy to miss. Row-level rules are the most sensitive item, because a misconfigured rule can expose data to the wrong readers, so test them with named test accounts before any production access. Confirm with your identity team how groups map to Superset roles, since authentication runs through Flask-AppBuilder and group mapping is configured separately from the dashboards. Ask the source database owner whether the query load that SPICE used to absorb is acceptable on live queries, because that load now falls on the warehouse. Finally, confirm current Superset version support and the upgrade path with your operations team before you go live, since upgrades must be tested in staging.

Which QuickSight capabilities map to Superset, and where the gaps are

This table maps the main QuickSight capabilities to their nearest Apache Superset equivalent and marks each as clean, needs rework or gap. Use it to scope the rebuild, then confirm chart types and features against the Superset version you plan to deploy, with 6.1.0 as the documented reference. The main takeaway is that data access and dashboards carry over with rework, while SPICE, per-session embedding and some sharing behavior need a deliberate design decision.

Capability	QuickSight	Apache Superset	Status
Datasets and direct SQL	Datasets on Athena, Redshift or other sources, with custom SQL	Connects to any SQL source through a Python DB-API driver and SQLAlchemy dialect; SQL Lab for ad hoc queries	Clean, provided the driver for your source is installed
SPICE in-memory cache	Imported copies of data stored in SPICE with scheduled refresh	No equivalent store; relies on the source database, optional caching layer and query engine performance	Gap, needs a caching or warehouse design decision
Analyses and dashboards	Analyses exported as asset bundles, then rebuilt as dashboards	Charts and dashboards are rebuilt in the UI; bundles serve as a specification, not an import	Needs rework, rebuild each dashboard
Calculated fields	Calculated fields defined in the dataset or analysis	Virtual datasets with SQL expressions and custom metrics in the semantic layer	Needs rework, move logic into SQL or metric definitions
Parameters and filters	Parameters, controls and filter actions	Native filters and dashboard-level filters; confirm control behavior for your version	Needs rework, test each interaction
Chart types	Broad set of visual types including KPI, pivot and custom visuals	Large built-in chart library; confirm specific types such as pivot or geospatial charts in your release	Needs rework, verify each chart type
Sharing and reader access	Users and groups with Author, Reader and Pro roles	Roles and permissions managed per dashboard and per dataset, mapped from identity groups	Needs rework, redesign role mapping
Row-level security	Row-level permission datasets applied to users or groups	Row-level security rules defined on datasets and tied to roles; confirm rule scope in your version	Needs rework, rewrite rules and test them
Scheduled email and alerts	Scheduled email reports and threshold alerts	Alerts and reports require the caching layer and Celery worker components	Needs rework, deploy workers and mail settings
Embedding and SSO	Embedded reader sessions billed by capacity; federated SSO	Embedded SDK with guest tokens; OAuth2, LDAP and role mapping through Flask-AppBuilder	Needs rework, host app must enforce tenant isolation

What the QuickSight export gives you and what you must rebuild

A QuickSight asset bundle is a useful specification for the dashboards and datasets you are moving, but it is not a copy of the working migration. The cards below separate what the export carries from what your team must recreate in Superset, including connections, credentials, identity and the data itself.

Asset bundles are a rebuild specification

An asset bundle export gives you JSON or CloudFormation definitions of dashboards, analyses and datasets. Use these files to inventory every visual, calculated field, filter and dataset logic before you touch Superset. Treat them as reference documents, not as an import file, because Superset does not read QuickSight definitions directly. Check each dataset definition against the SQL it ultimately runs, since calculated fields often carry business rules that reviewers need to confirm.

The bundle excludes the underlying data

The export describes structure and logic but does not contain the rows behind your datasets. Any data held in SPICE must be reloaded from its source system, and that source must be reachable from your self-hosted Superset. Confirm with data owners which tables, files and extracts sit behind each dataset, and whether any of them exist only as SPICE copies with no upstream source you can still query.

Some sources fall outside the APIs

Not every data source a QuickSight analysis depends on is captured by the export APIs. Connections to certain sources, data prep steps and some file-based inputs may need to be documented by hand from the QuickSight console. Build a source register that lists each connection, its owner, its network path and its credential type, and reconcile it against the bundle contents before you decommission anything.

Recreate connections through DB-API drivers

Superset reaches Athena, Redshift and other SQL sources through a Python DB-API driver and a SQLAlchemy dialect, so each connection must be created again in the Superset database settings with the matching driver installed in the image. Validate every connection string in staging, confirm the driver version supports your engine version, and test the queries that your largest dashboards run, since performance can differ once SPICE is no longer in the path.

Handle credentials outside the dashboard

QuickSight often reuses IAM roles or service connections that are not visible in a dashboard definition. In Superset, store database credentials as environment-injected secrets or in a secrets backend that your platform team controls, not in exported files or the metadata database in clear text. Decide who may create connections, rotate passwords on a schedule, and document which IAM principal, if any, Superset will assume when querying AWS services.

Map AWS and QuickSight groups to Superset roles

QuickSight permissions are tied to users, groups and AWS identities, and those mappings will not carry over automatically. Superset supports LDAP and OAuth2 providers and maps groups to roles through AUTH_ROLES_MAPPING, so decide which identity provider is authoritative and which Superset roles correspond to your current Author, Reader and admin groups. Reproduce dataset-level and row-level access with Superset's own role rules and test each mapping with a representative account from every group.

The migration sequence from inventory to decommission

This sequence moves QuickSight dashboards to Superset in controlled stages, so each dashboard is proven against the same numbers before users depend on it. Each step ends with a named output that gates the next one. The result is a documented decommission record for QuickSight rather than an unverified switch.

Inventory dashboards, datasets and users
Start by listing every QuickSight analysis, dashboard, dataset, data source, SPICE dataset, scheduled refresh, and reader or author group, with its owner and last-viewed date. Export the definitions through asset bundles so you have a reference copy of what each dashboard computes, noting that the bundle holds definitions, not the underlying data. Mark which dashboards are actively used and which are candidates for retirement. The output is a signed-off inventory list that business owners have reviewed, and it becomes the scope for everything that follows.
Pilot with two or three representative dashboards
Select two or three dashboards that together cover your main patterns: a dataset read directly from a SQL source, a dataset that depends on SPICE, and one with row-level access rules. Connect Superset to the same sources, rebuild these charts and datasets, and configure a test role mapping that mirrors one QuickSight reader group. Run the pilot with a small group of business users in a staging environment that follows the upgrade and configuration practice for Superset. The output is a validated pilot with a short list of gaps, such as chart types or caching behavior that needed a workaround.
Rebuild and reconcile against QuickSight figures
Rebuild the remaining in-scope dashboards in Superset, starting from the asset bundle definitions and the agreed metric logic. For each KPI and filtered view, compare totals, counts and date-bucketed results between QuickSight and Superset using the same filters and time zone. Record any difference and its cause, whether it is a SPICE refresh timing gap, a rounding rule or a logic error. The output is a reconciliation report with each metric marked as matched or explained, and business owners sign off on it before cutover planning begins.
Run both tools in parallel
Keep QuickSight and Superset running side by side, both reading the same warehouse or database sources, for a period agreed with the business owners. Track refresh freshness, query cost on the source, dashboard load behavior, and any reconciliation drift that appears after the initial build. Confirm that Superset's caching and worker components, where you use alerts, reports or async queries, are operating as designed. The output is a parallel-run log that shows the two tools agree on the metrics that matter.
Cut over with a documented rollback plan
Write a cutover runbook that lists the order of dashboard moves, the user communication, the access mapping from QuickSight groups to Superset roles, and the named owner for each action. Define the rollback trigger and the exact steps to restore QuickSight access, and keep the QuickSight assets intact until the rollback window closes. Back up the Superset metadata database before the switch and rehearse the restore in staging. The output is an approved cutover runbook and a completed cutover with a record of who was notified and when.
Decommission QuickSight assets and record the outcome
After the agreed stable period, remove QuickSight scheduled refreshes, SPICE datasets, reader and author subscriptions, and the data source connections that no longer have a consumer. Confirm with your billing or procurement team that the subscription has been ended according to the contract terms you negotiated with AWS. Retain the asset bundles and reconciliation report in your records, as they document what the dashboards computed. The output is a decommission record that lists each removed asset, the approver, and the date.

How to replace SPICE with caching or a query engine in Superset

SPICE is QuickSight's in-memory store: you load a copy of the data into it, refresh it on a schedule, and dashboards read from that copy. Superset does not have an equivalent copy by default. It sends each chart query to the source database, and performance depends on the source's speed plus Superset's caching layer. Before you cut over, map every QuickSight dataset to one of two patterns: direct query with cache, or a precomputed table that the dashboard reads. Confirm which datasets currently use SPICE and how often each one refreshes, because that refresh interval is the freshness target you must match or renegotiate with the business.

The caching layer is optional in the architecture, but you will need it. Superset's architecture documentation says async queries, alerts, reports and dashboard thumbnails require the caching layer and the Celery worker and beat processes, and most installations use Redis and Celery for them. Plan the Redis instance, the worker and beat deployment, and their monitoring as recurring infrastructure, not a one-time setup. On the warehouse side, decide whether to add indexes, materialized views or summary tables for the heavy aggregations that SPICE used to absorb, or to place a dedicated query engine such as ClickHouse or Trino between the warehouse and Superset. The first option keeps the stack smaller; the second adds a service to operate but suits large, high-concurrency dashboards. Your choice should follow measured query cost, not preference.

Test before you commit. Replay the busiest QuickSight dashboards against the new setup with realistic filters, the same user count at peak, and the scheduled refresh windows, then record query latency and cache hit behavior. Include alert and report runs, since they compete with interactive users for workers. Ask your warehouse team what concurrency limits apply to the Superset service account, because that account will now carry the load SPICE refreshes used to carry. Whatever you choose, document the cache timeout per dataset so business owners know how stale a number can be.

What drives migration cost and duration

This table lists the factors that raise or lower the effort of moving QuickSight content to Apache Superset, with the reason each one matters and how to keep it contained. Use it to scope your own inventory before requesting a written quote, since no fixed fee or duration applies across estates of different size.

Driver	Why it changes effort	How to keep it down
Number of dashboards and calculated fields	Each dashboard is rebuilt by hand in Superset charts and dashboards, and calculated fields must be re-expressed as SQL expressions or virtual datasets.	Inventory assets from the asset bundle export, retire unused dashboards, and move shared calculations into reusable SQL views in the warehouse.
Row-level rule complexity	QuickSight row-level security rules are defined per dataset and must be recreated with Superset row-level security filters tied to roles or users, then tested for each group.	Replace per-user rules with group-based rules, document the expected result per role, and test with representative accounts before cutover.
Number of distinct sources and drivers	Each source needs a Superset database connection, a SQLAlchemy dialect and driver installed in the image, and credentials managed outside the app.	Consolidate sources where possible, standardize on the drivers you already run, and build one reviewed container image with all required drivers.
SPICE dependence	Datasets that rely on SPICE imports need a decision on caching, query engine or a refresh schedule, since Superset queries the source directly unless a cache or an upstream engine is added.	Identify which SPICE datasets are large or slow, then choose between warehouse-side materialized views, a query engine or Superset caching for each one.
Embedded consumers	Applications that embed QuickSight dashboards must be changed to use Superset's embedded SDK and guest token flow, and the host application must enforce tenant isolation.	List every embedding point early, decide which ones move in the first wave, and confirm the isolation model with your application owners.
Identity integration	Reader groups in QuickSight must map to Superset roles through LDAP or OAuth group mapping, and users who log in through federated identity need matching accounts.	Map each QuickSight group to a Superset role on paper first, and confirm your identity provider can send the group claims Superset expects.
Data validation needs	Numbers on migrated dashboards must match QuickSight output, which requires side-by-side queries, sign-off by data owners and handling of rounding or time zone differences.	Agree a small set of key metrics with business owners, compare them on the same date ranges, and record the results as acceptance evidence.
Internal team Superset experience	Teams new to Superset need time to learn chart configuration, the metadata database, upgrades and the caching and worker components, which adds effort on both build and run.	Ask the implementation partner for a knowledge transfer plan, and confirm which tasks your staff will perform after handover.

How the migration differs by starting point

A small team with a handful of dashboards on Athena usually has the simplest path. The data already sits in S3 and is queried through Athena, so Superset can connect to Athena directly through its SQLAlchemy dialect, and the team can skip SPICE altogether. Start by exporting the asset bundle so you have a written record of each analysis, then rebuild the two or three dashboards that people actually open each week.

Sequence emphasis: connect Superset to Athena, confirm query cost and timeouts on the heaviest dataset, then rebuild dashboards one at a time.
Main risk: unmanaged Athena scan costs, because cached results from SPICE no longer shield the query path.
Keep out of scope in phase one: alerts, scheduled email reports and thumbnails, which need the caching layer and Celery workers.
Keep out of scope in phase one: custom themes and every rarely used sheet, which can be retired rather than rebuilt.
Keep out of scope in phase one: a full high availability design, since a single well-backed-up instance may match the team's needs.

Before cutover, confirm with your Athena administrator which IAM role Superset will use and whether workgroup result locations and query limits fit your reporting schedule.

What usually goes wrong and how to prevent it

Most QuickSight-to-Superset problems come from assumptions that carried over silently: how metrics are calculated, how access is filtered, how much load live queries place on the warehouse, and how the platform is configured and upgraded. Each card below names one of these failure points and the check that catches it before users do.

Metric definitions drift between tools

QuickSight calculated fields, Superset virtual datasets and metrics can all compute the same KPI with different null handling, time zones, rounding or distinct-count logic. Before cutover, pick a sample of executive KPIs and compare the QuickSight output with the Superset output for the same date range and filters. Record each agreed definition in one place, such as the Superset dataset description, so later edits go through review.

Row-level rules that do not match

QuickSight row-level security datasets and Superset row-level security filters are configured separately and evaluate differently for users in several groups. Test each reader group with a named test account and compare visible rows against the QuickSight result, including users who belong to more than one group. Confirm that group names from your identity provider map to the roles you expect through AUTH_ROLES_MAPPING.

Underestimated live query load

SPICE served dashboard queries from an in-memory copy, so warehouse cost and concurrency were often hidden from dashboard owners. Superset sends each chart query to the database unless caching is set up, so a dashboard with many charts and many viewers can multiply warehouse load. Before go-live, measure query volume and warehouse cost at peak refresh times, and set cache timeouts per dataset that match how fresh the data must be.

Scheduled reports left out

Alerts, scheduled email reports and dashboard thumbnails depend on the caching layer and Celery worker and beat processes, not on the web application alone. Teams that only deploy the web container often find that subscriptions silently stop working. Inventory every QuickSight email schedule and confirm that the worker, beat and caching components are deployed, monitored and restarted automatically in your environment.

SECRET_KEY and metadata database setup

Superset refuses to start without a user-specified SECRET_KEY, and changing it without PREVIOUS_SECRET_KEY can lock out stored credentials. The metadata database should be PostgreSQL or MySQL in production, not the SQLite default used by quickstart installs. Store the key in your secrets manager, document the rotation procedure, and confirm the metadata database version falls within the supported range in the configuration documentation.

Upgrade breakage between versions

Superset releases can change behavior, configuration or database migrations, and an upgrade applied straight to production can stop dashboards from rendering. Before each upgrade, back up the metadata database, run the upgrade in a staging copy, then run superset db upgrade and superset init. Read UPDATING.md for breaking changes between your current version and the target, and keep the previous container image so you can roll back.

Questions buyers ask before moving off QuickSight

How much effort does a move from QuickSight to Superset take?

The effort depends mostly on how many dashboards, datasets and calculated fields you have, how many of them rely on SPICE, and how complex your row-level rules are. Each dashboard has to be rebuilt as a Superset chart and dashboard, so the count of visuals matters more than the count of users. Teams that already run SQL-based analyses on Athena or Redshift usually find the rebuild simpler than teams whose datasets were built from many file uploads or joins inside SPICE. Ask for an inventory of analyses, datasets, data sources and access rules before agreeing on any scope, because that inventory is what turns a rough estimate into a written plan.

How long does a QuickSight to Superset migration typically take?

No researched figure for migration duration is available, so treat any number you hear as unverified. The timeline varies with the factors that drive effort: the number of dashboards and datasets, the number of data sources, the depth of row-level security, the level of change management needed for users, and whether the new stack must be hardened and documented to meet your internal standards. Parallel running, where business users compare old and new dashboards for a period, adds time but lowers cutover risk. Ask any implementation partner for a written schedule tied to a defined scope, with milestones for staging, validation and cutover.

What does the client team need to provide for the migration?

The client team typically provides access to the source AWS accounts, a list of the people who own each dashboard, the business definitions behind key metrics, and a named approver for each set of dashboards. On the technical side, you need a place to host Superset, a metadata database on PostgreSQL or MySQL, read access to the warehouse or query engine, and an identity source such as your existing SSO provider or LDAP. Expect to decide who will own the stack after go-live, since upgrades and access reviews need a permanent owner.

Can an internal team migrate QuickSight to Superset without outside help?

An internal team can do it if it has people comfortable with SQL, Python-based deployment, container or Kubernetes operations, and identity integration. The main risks for internal teams are underestimating the rebuild of row-level rules, skipping the metadata database backup before upgrades, and running a non-production configuration in production. Superset's documentation calls out that the SQLite default and the Docker Compose PostgreSQL container are not recommended for production, so a production deployment needs deliberate design. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own environment and can work alongside an internal team on a fixed-scope basis.

Can QuickSight dashboards be exported directly into Superset?

No. QuickSight does not export dashboards in a format Superset can import, so the practical path is to rebuild them. You can use QuickSight asset bundle export jobs to obtain JSON or CloudFormation definitions of dashboards, analyses and datasets. Those definitions act as a specification for rebuilding charts, datasets and filters, but they are not an import file. Data is not included in the export, and some data sources are skipped by the APIs, so confirm coverage for your own assets before you rely on the bundle. Confirm these details with AWS documentation and a test export in your account.

What happens to SPICE data when we move to Superset?

SPICE is QuickSight's in-memory store, and its contents do not move to Superset. Superset connects directly to your SQL sources, so the decision is what replaces SPICE for each dataset. Common options are querying the warehouse directly, using Superset's caching layer for frequently viewed results, or using a query engine closer to the data. Direct querying depends on warehouse performance and cost, so test the heaviest dashboards first. Datasets that were built only from uploaded files need a new home in a database before Superset can use them, and that step should be scoped explicitly.

How are QuickSight row-level rules rebuilt in Superset?

Row-level rules are rebuilt by recreating the access logic in Superset's security model and in the database layer that Superset queries. Superset supports OAuth2 providers, LDAP and database authentication through Flask-AppBuilder, and can map LDAP or OAuth groups to roles with the AUTH_ROLES_MAPPING setting. The data filtering itself must be verified against source-level permissions, and every rule should be tested with representative users before cutover. Document each rule, its owner and the test cases used. Confirm exact configuration keys and feature coverage against the Superset configuration documentation for your target version.

How are upgrades handled after Superset goes live?

Upgrades are a recurring task, and you should plan an owner and a staging environment for them from the start. The Superset upgrade documentation says to back up the metadata database, run superset db upgrade and superset init, test in staging first, and check UPDATING.md for breaking changes between versions. Keep the SECRET_KEY stable across upgrades, because Superset requires one to start and supports rotation with PREVIOUS_SECRET_KEY. Superset 6.1.0 was released on May 13, 2026, and new Kubernetes deployments should consider the Apache Superset Kubernetes Operator, since the Helm chart is marked deprecated in current development documentation. DeployOpen offers upgrades and ongoing support as retainers.

How DeployOpen scopes and runs a QuickSight to Superset migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the cloud accounts, data centers or air-gapped networks where the Superset stack will run. For a QuickSight move, that means the Superset application, its metadata database, any caching and worker components, the network paths to Athena, Redshift or other SQL sources, and the identity integration are all planned within the client's environment. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope rather than from a published price list. DeployOpen does not publish a price list, so the first useful step is a scoping conversation, not a purchase order.

The scope itself depends on what the client brings. Before a quote is written, the client should provide an inventory of QuickSight assets: every dashboard, analysis, dataset and the SPICE datasets they depend on, along with the asset bundle exports the team has already taken. The client should also provide read access to the source databases, a named technical owner for each source, and a named business owner for each dashboard who can confirm that a rebuilt version matches the original. Row-level rules need a list of who sees what, and the identity team should confirm which groups in the identity provider will map to Superset roles. Where a dashboard has no owner, the scope should say so, because the decision to rebuild, merge or retire it is a business decision that the migration cannot make on its own.

Ongoing responsibilities are a separate line in the agreement. Once Superset is in production, upgrades, backups of the metadata database and security patches continue after the project closes, and these are typically covered by a retainer for ongoing support, upgrades and continuous testing. The client should ask for the retainer terms in writing and confirm who performs each upgrade, how staging tests are run and who is on call for the alerting and report components. Ask the provider to document each deployment decision, so that the team that inherits the platform can operate it without the migration team on hand.

Migrate from Amazon QuickSight to Apache Superset