Qlik Sense or Apache Superset: which fits your BI estate
If a Qlik renewal, a client-managed release approaching end of support, a licensing change or a data residency requirement has put your Qlik estate under review, the first question is whether your analytics value sits in the Qlik application layer or in the warehouse beneath it. Qlik Sense fits best where business users explore data associatively in memory, where years of load scripts and set analysis encode business logic that people rely on, and where the estate is client-managed on Windows. Apache Superset fits best where SQL-first analysts already work against a warehouse, where that warehouse is the system of record, and where you want Apache-2.0 licensing with no paid edition to budget for. Superset does not replicate the associative engine, so it suits dashboards and governed SQL datasets better than free-form selection across many linked tables.
The decision turns on three questions you can answer from your own environment. First, where does the logic live today: in Qlik load scripts and QVF apps, or in a warehouse, dbt models or views that a Superset dataset could query directly? Second, who builds dashboards: a central BI team comfortable with SQL, or business analysts who expect drag-and-drop exploration inside an app? Third, how many users need interactive exploration rather than viewing published dashboards, since that count drives both licensing under Qlik and the sizing of Superset's caching and worker layer. Ask Qlik to quote against your actual named users and session patterns, and inventory your load scripts before you assume either platform's costs.
Which workloads favor each product
This table maps common Qlik Sense and Apache Superset workloads to the platform that usually fits better and the reason behind it. Several answers depend on your warehouse and load script estate, so read the last column as a starting point to confirm against your own data.
| Workload | Better fit | Reason and what to confirm |
|---|---|---|
| Associative exploration across many sources | Qlik Sense | Qlik loads data into an in-memory associative model, so users click through fields and see related and excluded values across sources. Superset relies on explicit SQL datasets and filters, so confirm how much exploration users need before choosing. |
| Warehouse-centric reporting | Apache Superset | Superset queries the warehouse directly through SQLAlchemy, so the warehouse stays the source of truth. This fits best when transformations already live in SQL or dbt. |
| Heavy Qlik load script estate | Depends on script estate | Scripts that reshape data in Qlik must move into SQL or dbt before Superset can match them. Estates with simple scripts migrate faster than those with large chains of transformations and set analysis. |
| Large reader populations or embedded dashboards | Apache Superset | Superset is Apache-2.0 with no paid edition, so the software cost does not scale with reader count. Confirm the infrastructure, caching and worker sizing for your concurrency, since those costs grow with use. |
| Governed metrics and shared definitions | Depends on current modeling | Qlik keeps measures in app logic, while Superset defines metrics on datasets. Governed metrics in a semantic layer or dbt favor Superset, but teams that rely on app-level measures need that logic rebuilt first. |
| Teams with strong SQL skills | Apache Superset | Analysts who write SQL can build datasets, charts and dashboards directly, and their queries stay visible for review. Teams without SQL skills may need training or a BI developer during the transition. |
| Self-service exploration by business users | Qlik Sense | Qlik's selection model and app design suit users who explore without writing queries. Superset asks users to work with datasets and charts, so plan training and curated datasets if you move this group. |
| Operational ownership and skills | Depends on internal capacity | Superset adds a metadata database, caching and Celery workers that your team must run and upgrade. Confirm who will own patching, backups and upgrades before committing. |
How Qlik's associative engine differs from querying the warehouse
Qlik Sense and Apache Superset answer selections in fundamentally different places. In Qlik, a load script pulls data from sources, transforms it and loads it into the engine's memory as an in-memory data model. The associative engine then links every field and value, so a click on one filter immediately recalculates which values in every other field remain possible, with no SQL issued at click time. Superset works the other way round. Its datasets point at tables or views in the connected database, and each chart, filter or drill sends a SQL query through SQLAlchemy to that database when it renders. Superset does not hold a copy of the data model, so its interactive speed depends on the warehouse, the query design and any result caching in front of it.
This difference points to a workload decision. An in-memory model tends to suit a bounded, curated data set that many users explore interactively with fast, cross-filtered selections, and where the team is comfortable keeping transformation logic in the load script. A warehouse-backed model suits data that is already large and maintained in the warehouse, dashboards with many concurrent viewers, and teams that want transformations in SQL or dbt where they can be version-controlled and reused. Before choosing, have the data engineering team measure the warehouse's response on your heaviest dashboard queries and confirm that the warehouse can absorb peak concurrency. Those two numbers, not the BI tool's logo, usually decide whether the Superset approach holds up.
Superset also needs more components than a single desktop-style model. The metadata database stores dashboards, datasets and users, and the architecture documentation lists an optional caching layer and optional Celery worker and beat processes. Alerts and reports, async queries and dashboard thumbnails depend on the caching layer and workers, and most installations use Redis and Celery for them. Plan for these services as part of the build, with their own patching, monitoring and capacity, and confirm which of these features your users need on day one. Teams that rely on scheduled reports or thumbnails should test that path in staging before cutover.
Where your data sits and who controls the stack
Qlik Sense and Apache Superset differ most in where the software runs, where metadata and cached results live, and who signs in and proves controls. The cards below set out those decisions so you can check each one against your own hosting and compliance requirements before you choose.
Client-managed Windows or Qlik Cloud
Qlik Sense Enterprise on Windows is client-managed software that your team installs, patches and operates on servers you control. Qlik Cloud is a SaaS option that Qlik hosts and manages. Confirm which deployment your data residency rules allow, who holds the Windows and database administration duties, and which Qlik release train your team can keep current. Superset has no Windows dependency, so the hosting choice moves to Linux containers or virtual machines in your own cloud or data center.
Superset in your own environment
Superset runs in your public cloud account, a private data center or an air-gapped network, because it is open-source software that you deploy yourself. Queries go directly from Superset to your warehouse or databases, so the data path stays inside the network boundary you define. Check that every SQL driver you need can be installed offline, and that your own build pipeline can supply Superset images and Python packages in an isolated environment.
Metadata in PostgreSQL or MySQL
Superset stores dashboards, charts, users, roles and saved queries in a metadata database, which must be PostgreSQL or MySQL for production. The Superset configuration documentation lists supported versions as PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. Plan backups, encryption at rest and access to this database as part of your data protection scope, because it holds business definitions and sharing rules that Qlik keeps inside its own application files.
Identity through database, LDAP or OAuth
Superset supports database, LDAP and OAuth authentication through Flask-AppBuilder, and it can map LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. Qlik Sense uses its own user and group model with directory integration. Decide which directory is authoritative, test group-to-role mapping with real leaver scenarios, and confirm how row-level access is enforced in the warehouse, since Superset dataset filters alone do not replace database-side policies.
Secret key and configuration control
Superset refuses to start without a user-specified SECRET_KEY, a requirement introduced in version 2.1.0, and it supports rotation through PREVIOUS_SECRET_KEY. Store the key, database credentials and OAuth client secrets in your existing secrets manager rather than in image files. Assign an owner for configuration changes and record them, because these settings control encryption of stored connection credentials and session integrity.
Compliance evidence you produce
Neither Qlik nor Superset supplies your audit evidence on its own. You must document where data is stored, who has administrative access, how changes are approved, and how backups and restores are tested. DeployOpen can prepare these controls, configurations and evidence for your assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, so ask them early which artifacts they expect.
What a move from Qlik Sense to Superset involves
The sequence turns Qlik apps, load scripts and selections into SQL datasets, charts and dashboards that Superset serves from your own warehouse, with each step ending in a checked output. Your team owns the inventory and the business sign-off, while the technical rebuild can be done in-house or by an implementation partner under a written scope.
Inventory apps, data connections and users
List every Qlik Sense app, sheet, data connection, extension, scheduled reload and user group, and record which apps are published and which are used by whom. Identify the ODBC and other data connections behind each app, because these must be recreated in Superset against the warehouse. The output is a signed-off inventory that business owners have reviewed, with each app tagged for rebuild, retire or consolidate. Confirm the Qlik Sense release in use, since client-managed releases have defined support windows that affect the cutover date.
Export QVF files from the QMC
Export each in-scope app as a QVF file from the Qlik Management Console, deciding with or without data for each one. Store the files in a controlled location with a manifest that maps each QVF to its owner and inventory record. The export captures the app's load script and data model, which you will read in the next step to understand what the warehouse must provide. Qlik's own export guidance explains what published apps include and which elements, such as extensions and data connections, must be recreated by hand. The output is a complete set of QVFs with a checksum list and a note of anything the export did not capture.
Move load script logic into the warehouse or dbt
Read each load script and move its transformations, joins, calculated fields and data cleansing into SQL views or tables in the warehouse, or into dbt models where your team already uses dbt. Qlik's in-memory data model does not carry over automatically, so the rules that previously ran at reload time must run in the database and be tested there. Involve data owners to confirm definitions such as revenue, active customer or period boundaries. The output is a set of versioned SQL models with tests, and a reconciliation report showing that key figures match the Qlik results for a agreed sample of periods.
Rebuild selections as SQL datasets with cross-filters
Qlik's associative engine lets users select any field and see related values across the whole model, which Superset does not replicate by default. Build SQL datasets for each analytical grain and configure Superset dashboard filters and cross-filtering so that selections on one chart narrow related charts. Where a Qlik app depends on set analysis or complex exclusion logic, rewrite it as explicit SQL or as a documented metric. Confirm with users which selection behaviors they rely on, because some may be better served by a dedicated dataset rather than a single broad dashboard. The output is a dataset catalog with documented metrics and a list of behaviors that changed.
Rebuild dashboards and access rules
Recreate the in-scope sheets as Superset charts and dashboards, then map Qlik section access or user groups to Superset roles, using LDAP or OAuth group mapping where your identity provider is the source of truth. Confirm which Qlik-specific features, such as custom extensions, must be replaced with native Superset charts or a supported plug-in. Test row-level restrictions separately, because access rules in one tool must be proven in the other before users rely on them. The output is a dashboard inventory with owners, a role mapping document, and a test log showing that restricted users see only the data they are entitled to.
Test in staging against reconciled figures
Deploy Superset and the metadata database in a staging environment that mirrors production, and run the upgrade and install steps from the official documentation, including the SECRET_KEY setting and database backup. Compare dashboard results with the Qlik originals for agreed reports, record differences, and have business owners approve each one. Test performance under realistic query loads and confirm that scheduled reports and async queries work if you use them, since those need the caching layer and workers. The output is a signed test record for each dashboard, an issues list with owners, and a go or no-go decision from the business sponsor.
Cut over and retire Qlik access
Schedule the cutover with users, freeze changes to Qlik apps in scope, run a final export and reconciliation, and point users and bookmarks to the new Superset dashboards. Keep the Qlik environment read-only for an agreed period so that users can check historical figures, then remove reload schedules and licenses according to your contract terms. Keep the QVF archive and the reconciliation records as evidence of what was migrated. The output is a documented cutover record, a list of retired Qlik apps, and a support handover to the team that will run Superset, including its upgrade routine.
Running Superset in production: upgrades, secrets and workers
The first operating decision is the SECRET_KEY. Superset will not start until you set a user-specified value, a requirement added in version 2.1.0, so the key must be generated, stored in your secrets manager and injected at deploy time rather than left at a placeholder. When you need to rotate it, the configuration documentation describes setting PREVIOUS_SECRET_KEY alongside the new key so existing sessions and encrypted values can still be read during the transition. Plan the rotation as a change with a named owner, and confirm the exact steps for your installed version in the Superset configuration docs before you touch production.
Upgrades carry the most operational risk. The upgrade documentation tells you to back up the metadata database first, then run superset db upgrade and superset init, and to test the sequence in staging before production. Before any version jump, read UPDATING.md in the repository for breaking changes, since configuration keys, dependencies and dashboard behavior can change between releases. Confirm that your metadata database is within the supported range listed in the configuration docs (PostgreSQL 10 to 17, MySQL 5.7 and 8.x) and that your backup can be restored, because the database holds dashboards, datasets, chart definitions and user roles that Qlik-migrated content will depend on.
Decide early on the runtime topology. The Superset architecture documentation notes that alerts and reports, async queries and dashboard thumbnails need the caching layer and Celery workers, which most installations run on Redis and Celery. For Kubernetes, the 6.1.0 documentation describes the official Helm chart, but the current development documentation marks that chart as deprecated for new deployments and points to the Apache Superset Kubernetes Operator. Confirm with your platform team which path you will support, and budget for the people who run whichever one you choose, since your staff, not a vendor license, will own patching and on-call.
Questions buyers ask before choosing Superset over Qlik
What does switching from Qlik Sense to Superset cost, and what drives it?
The switch cost is mostly labor and infrastructure, and the Qlik license is only one line in the comparison. Superset itself is licensed under Apache-2.0 and has no paid edition, so the software line is zero. Recurring costs are the servers or containers for Superset, its metadata database (PostgreSQL or MySQL), any caching and worker components, warehouse compute for queries, and the staff who run upgrades and access control. One-time costs include rebuilding Qlik apps as SQL datasets and charts, moving load script logic into the warehouse or a transformation tool, and testing. The biggest variables are how many apps you have, how much logic lives in load scripts, and how much warehouse capacity your queries will consume. Ask any implementation partner for a quote that splits these into one-time and recurring items, and ask for the Qlik renewal figure you are comparing against so the numbers line up.
How long does a Qlik to Superset migration take?
The pace is set by the number of apps, the complexity of their load scripts and set analysis, and the state of your data warehouse, not by Superset's installation. A small estate of simple apps can move far faster than one with many interlinked QVF files and heavy transformation logic. Qlik client-managed releases are supported for two years, so an older install may force your timeline. Plan around these inputs: an inventory of apps and data connections, a decision on where each transformation will live, a staging environment for testing Superset upgrades, and a cutover window with parallel running. Superset's upgrade guidance asks you to back up the metadata database, run superset db upgrade and superset init, and check UPDATING.md for breaking changes, so build those steps into the schedule. Ask for a timeline tied to a written, phase-by-phase scope rather than a single headline duration.
What skills and access does the client team need for Superset?
Your team needs SQL skills more than anything else, because Superset queries your warehouse directly and its datasets, metrics and charts are expressed in SQL. Someone must also understand the warehouse schema, its performance characteristics and who owns each table. Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, so you need network access and a service account with read permissions for the warehouse. For deployment, expect practices such as configuration management, secret handling for the SECRET_KEY that Superset requires at startup, and a repeatable upgrade process. If you want dashboards and definitions under version control, plan for Git and a deployment pipeline, since Superset content is not stored in Git by default. Confirm these needs with your own platform team before committing to a scope.
Can an internal team migrate from Qlik to Superset without outside help?
An internal team can do it alone if it has the SQL depth, warehouse access, and capacity to run a parallel project while keeping Qlik working. Teams with a strong data engineering function and modest Qlik estates are the most likely to succeed without help. Outside help is usually most valuable for the parts that are hardest to repeat: converting set analysis and associative behavior into SQL, designing the metadata and security model, setting up authentication through OAuth or LDAP with role mapping, and hardening and backing up the deployment. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables. Ask any provider to split the work into what your team will do and what they will do, and confirm how knowledge transfer and documentation are handled.
Does Superset match Qlik's associative selections?
Not in the same way. Qlik's associative engine keeps data in memory and highlights related and excluded values across a whole model when a user selects something. Superset does not replicate that engine. It sends queries to your warehouse, so cross-filtering is built from dashboard filters that generate SQL, and the query results determine what is shown. This works well for dashboards with well-defined dimensions and a warehouse that answers quickly, but it changes the user experience for people who rely on free exploration of green, white and grey values. Before deciding, test your most-used Qlik apps with real users on sample data and check whether the cross-filter behavior meets their needs. Confirm the exact behavior in the Superset version you plan to run, since features change between releases.
How does Superset licensing compare with Qlik Cloud capacity pricing?
Superset has no license fee to compare against Qlik's commercial pricing, because it is released under Apache-2.0 and the project has no paid edition. Qlik Sense Enterprise on Windows is a client-managed product, and Qlik Cloud is a SaaS option hosted and managed by Qlik, so the cost models differ. When you compare, the open-source side moves the spend to infrastructure, warehouse compute, and people, while the Qlik side pays for the software and its hosting or capacity. Ask Qlik for a written quote that states the licensing unit, what capacity is included, and how renewal and overage work. Then ask your provider to price the self-hosted stack using the same time horizon, with infrastructure, support and staff listed separately so you can compare like with like.
How DeployOpen helps you evaluate and move off Qlik
DeployOpen plans and implements self-hosted open-source BI inside your own infrastructure, so the Qlik Sense vs Apache Superset decision rests on your data, your licensing position and your release calendar. Engagements start with a written scope, and the work is documented and handed over to your team.
How we scope
- Inventory which Qlik apps, load scripts and users are in use, and which are still needed
- Define the warehouse sources, Superset metadata database and authentication model in writing
- Agree fixed-scope deliverables and timelines before any build work starts
How we build
- Deploy Superset in your cloud account, data center or air-gapped network with PostgreSQL or MySQL metadata
- Rebuild priority dashboards as SQL datasets and move script logic into the warehouse layer
- Configure LDAP or OAuth group mapping and test access against your role model before go-live
How we hand over
- Document the architecture, configuration, SECRET_KEY handling and backup procedures
- Run acceptance tests in staging and record the results for your reviewers
- Provide an upgrade runbook that covers database backups, upgrade steps and UPDATING.md review
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer
- Prepare systems and evidence for compliance assessments, while independent auditors issue any reports
- Keep the Qlik export and cutover checklist current until your last dashboard is retired
