Why QuickSight may not fit when BI must run outside AWS
If your warehouses sit on-premises, in another cloud, or inside a customer-controlled environment that AWS cannot host, Amazon QuickSight is the wrong place to run BI. Self-hosted Apache Superset and Metabase are the two open-source options that run next to the data, so the BI layer can be deployed in the same network, cloud account or air-gapped zone as the sources it queries. The constraint is QuickSight's hosting model: it is an AWS-managed service, and the question is less about features than about where the BI control plane and its metadata are allowed to live.
The decision depends on where your warehouses and your users sit, so map both before comparing products. List every source the dashboards read from, including any non-AWS warehouse, on-premises database or SaaS export, and note which of them must stay inside a specific boundary. Then list who logs in, from which networks and through which identity provider. A single Superset or Metabase instance can reach several environments if network paths and database credentials allow it, but a deployment that must stay inside one customer environment usually needs its own instance there. Confirm with your security and data governance teams whether dashboard definitions, cached results and user activity count as regulated data in your context.
Before you commit, check three things with your own environment rather than assumptions: whether your residency or contractual terms prohibit AWS-hosted metadata, which connectors and drivers your sources need, and whether your identity and access model can be met by the open-source edition or requires a paid plan. Write these answers down as the scope for a pilot, because they determine the hosting pattern, the authentication setup and the size of the migration that follows.
What a non-AWS BI deployment must satisfy
A BI stack that runs outside AWS has to answer four questions before any dashboard is rebuilt: where the application and its metadata live, which warehouses it can reach, how people sign in, and who holds the secrets and upgrades. Each card below is a decision or check that connects to the others, so settle them in this order.
Where the application and metadata run
Apache Superset has four components: the Flask and React application, a metadata database, an optional caching layer and optional Celery workers. Metadata is stored in PostgreSQL or MySQL, and the SQLite default is not meant for production. Decide which environment hosts the application, the metadata database and the cache, and confirm that the cache and workers can reach the same network segment as the warehouse. Keep the metadata database inside your own boundary and back it up before every upgrade.
Reachable SQL warehouses
Superset connects to any SQL datastore that has a Python DB-API driver and a SQLAlchemy dialect, so warehouses in another cloud, on-premises or in a customer environment can be used without AWS services. Inventory each source, confirm its driver and dialect exist, and test network paths, certificates and service accounts from the host that will run queries. Metabase also connects to many SQL databases, but confirm the specific driver and version for each source in its supported list.
Identity through LDAP or OAuth
Superset is built on Flask-AppBuilder and supports OAuth2 providers, custom OAuth2 servers using the code flow, and LDAP. Its AUTH_ROLES_MAPPING setting maps directory groups to Superset roles, so group design in your identity provider drives access. In Metabase, Google sign-in and LDAP are available in the open source and Starter plans, while SSO through JWT, OIDC or SAML, advanced group sync and SCIM provisioning require Pro or Enterprise. Check the plan before you promise SSO to users.
Secret key and configuration ownership
Superset requires a user-specified SECRET_KEY to start, a requirement added in version 2.1.0, and it supports rotation through PREVIOUS_SECRET_KEY. Store the key and database credentials in your secrets manager rather than in image files, and document who can rotate them. Assign a named owner for configuration, so every change to the key, the metadata connection and the auth settings is tracked in version control.
Upgrade and version ownership
Superset upgrades require backing up the metadata database, running superset db upgrade and superset init, testing in staging first and checking UPDATING.md for breaking changes. Metabase runs its application database migrations automatically, and its LTS releases are supported for 14 months. Decide who watches release notes, who schedules upgrades and who signs off, because a non-AWS stack has no vendor doing this for you. Confirm the support model in any quote.
Which self-hosted option fits which constraint
This table compares Apache Superset and Metabase against the constraints that usually drive a move off QuickSight outside AWS, such as licensing, identity, air-gapped operation and operating load. Read each row against your own warehouse, user model and security requirements, then shortlist the column that fits the majority of them.
| Constraint | Apache Superset | Metabase |
|---|---|---|
| License model | Apache-2.0 with no paid edition; all features ship in the same codebase | Open core: AGPL open source edition with unlimited users; enterprise directory under the Metabase Commercial License |
| Non-AWS or on-premises data sources | Connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect | Connects to a broad set of databases; confirm your specific warehouse driver in the Metabase docs before committing |
| Self-service questions without SQL | Possible, but SQL Lab and chart building suit analysts more than business readers | Strong fit: query builder lets business users ask questions without writing SQL |
| SSO and group mapping | OAuth2, LDAP and AUTH_ROLES_MAPPING through Flask-AppBuilder on the open source build | SSO, SAML, JWT, OIDC and SCIM need Pro or Enterprise; open source and Starter support Google sign-in and LDAP |
| Row and column level permissions | Row-level rules are configured in the open source build; confirm the rule model against your access design | Row and column level permissions require Pro or Enterprise |
| Air-gapped deployment | Self-hosted by design; confirm offline package and dependency sourcing with your team | Air-gapped deployment is offered only on the Enterprise plan |
| Alerts, reports and async queries | Requires the optional caching layer and Celery worker and beat components, usually Redis and Celery | Runs as a single application with a required application database; confirm scheduling needs for your environment |
| Application database | Metadata stored in PostgreSQL or MySQL; SQLite is not recommended for production | Embedded H2 for demos; PostgreSQL recommended for production, with MySQL or MariaDB also supported |
| Narrower option: Lightdash | Not a direct substitute for multi-source exploration; consider only for dbt-centric teams | Lightdash is MIT for content outside its ee directory, with a separate license for ee code; check which parts you need |
Where the AWS-hosted model stops meeting the constraint
The AWS-hosted model stops fitting when the constraint applies to where the BI service runs, including where dashboard metadata and cached results are stored. Amazon QuickSight is an AWS-managed service, so the first question is whether its hosting and regional options meet your requirement in writing. Confirm, against current AWS documentation and with your AWS account team, which AWS Regions the service is available in, whether any component can run outside AWS, and where each type of data is kept. Do not assume that an AWS-managed service can follow a workload into your data center, another cloud or an air-gapped network. If the answer is no, the requirement points toward a self-hosted tool that you deploy next to the data.
Next, turn each constraint into a concrete check. List every system the BI layer must reach, including any warehouse outside AWS, and confirm connectivity from the BI tier in your own environment. Apache Superset connects to any SQL datastore that has a Python DB-API driver and a SQLAlchemy dialect, so the first test is whether your non-AWS warehouse meets that condition. Its metadata database must be PostgreSQL or MySQL, which your team would host and back up. Authentication can use database accounts, LDAP or OAuth through Flask AppBuilder, so record which of these your identity provider and network policy allow before you select a target.
Plan the content move before you choose the target tool. The sibling export page explains what QuickSight asset bundles contain and why the underlying data is not part of the export, so plan to rebuild dashboards and datasets from a specification instead of expecting a file transfer. For each dashboard, confirm which source it reads, which rules restrict rows, and who owns it. Have business owners sign off on that inventory before any target environment is built, because the inventory determines the scope of the rebuild.
Choosing a deployment path by environment
Teams running BI inside a data center or an isolated network need every dependency to be reachable from inside that boundary. Apache Superset is Apache-2.0 licensed with no paid edition, so the software itself carries no license gate, but the install still pulls Python packages, container images and database drivers that must be mirrored or staged internally. Metabase is different: its air-gapped deployment is available only on the Enterprise plan, so an isolated Metabase project needs that commercial decision made early.
- Network egress: Confirm whether the Superset or Metabase hosts can reach public package indexes, container registries and license servers, or whether all artifacts must be copied in through an approved transfer process.
- Image registry access: Confirm that an internal registry holds the Superset, PostgreSQL, Redis and Celery images, or that the team has a documented process to update them.
- Metabase Enterprise for air-gapped use: Confirm with Metabase whether an isolated deployment requires the Enterprise plan and what it costs, since the open source edition does not include that option.
- Kubernetes guidance: Superset's Helm chart is marked deprecated in current development documentation, which points new deployments to the Apache Superset Kubernetes Operator. Confirm which method your platform team will adopt and whether the operator's images can be mirrored.
- Metadata and upgrades: Plan a backup and staging environment for the metadata database, because upgrades run against it.
Before committing, ask the platform team to write down every outbound dependency so the install can be tested inside the isolated network.
When the data lives in Azure, Google Cloud or another provider, the BI stack can run next to the warehouse without AWS-hosted services. Looker is the relevant contrast here: Google documents that Looker (Google Cloud core) instances are hosted by Google in Google Cloud and are not available for customer-hosted or multicloud environments. Self-hosting Superset or Metabase avoids that constraint, but it moves operating responsibility for compute, networking and upgrades into the team's own cloud account.
- Warehouse connectivity: Confirm that Superset's database drivers (Python DB-API with a SQLAlchemy dialect) or Metabase's supported drivers exist for the target warehouse and can reach it over private networking.
- Egress and private endpoints: Confirm whether the BI nodes can reach the warehouse privately and whether outbound traffic to package sources is permitted by the cloud's network policy.
- Managed metadata database: Confirm that a managed PostgreSQL or MySQL service in the chosen cloud falls within the supported versions, PostgreSQL 10 to 17 or MySQL 5.7 and 8.x for Superset.
- Identity provider: Confirm whether the cloud's identity service supports the OAuth2 or LDAP paths Superset uses, or whether Metabase SSO requires the Pro or Enterprise plan.
- Cost ownership: Ask who pays for the compute, storage and cache services, because these recur in the cloud account rather than in a vendor invoice.
Ask the cloud team to confirm the network path to the warehouse before any dashboard work starts.
Some organizations deploy analytics inside a customer's environment, for example a partner-run tenant or a regulated client's own infrastructure. The customer usually controls the cloud account, network policy, identity provider and change windows, so the BI stack has to fit those controls rather than set them. Superset's requirement for a user-specified SECRET_KEY at startup, and its support for rotating it with PREVIOUS_SECRET_KEY, belong in the handover checklist for any operator who did not build the system.
- Change control: Confirm which upgrade path the customer accepts, since Superset upgrades call for a metadata backup,
superset db upgrade,superset initand staging tests. - Access model: Confirm whether the customer's identity provider maps to Superset roles through AUTH_ROLES_MAPPING, or whether Metabase group sync requires Pro or Enterprise features.
- Secrets handling: Confirm where the SECRET_KEY and database credentials are stored and who holds rotation rights.
- Support boundaries: Confirm who answers for a failed upgrade, the customer's team, the software maintainer or an external operator.
- Documentation: Ask for the customer's runbook template so the BI deployment can be recorded in the same format as other systems.
Agree these boundaries in writing before installation, since they determine who can act when a dashboard or upgrade fails.
How to deploy Superset or Metabase under the constraint
This sequence takes a team from a stated hosting constraint to a self-hosted Superset or Metabase instance that connects to the right warehouses, signs users in through the organization's identity provider, and can be upgraded safely. Each step ends with a check that the team can verify before moving on.
Confirm the constraint and the warehouses
Start by writing down where the BI tool must run (on-premises, another cloud or inside a customer environment) and which databases and warehouses hold the data that dashboards will query. Include any non-AWS sources and whether each one can be reached from the host network. The platform owner and the data owner should sign off on this list. Done means every source has a named owner, a network path, and a read-only database account reserved for the BI tool.
Provision a production metadata database
Create PostgreSQL or MySQL for the BI tool's own metadata. Superset's architecture documentation says the SQLite default of Quickstart and PyPI installs is not recommended for production, and the Docker Compose PostgreSQL container is not recommended for production either. For Metabase, the documentation recommends PostgreSQL for production and notes that the embedded H2 database is for demos. Confirm the database version against the supported list in the configuration or installation docs. Done means the database is reachable from the application nodes, backed up on a schedule, and not shared with a data warehouse workload.
Set the secret key and application configuration
For Superset, set a user-specified SECRET_KEY before first start, since current versions require one. Store it in a secrets manager and inject it at runtime rather than committing it to a configuration file. Record how to rotate it using PREVIOUS_SECRET_KEY. For Metabase, set the application database connection and the site URL, and keep the configuration in the same secrets store. Done means the service starts cleanly with a non-default secret, and the key and rotation procedure are documented by the platform team.
Wire identity and group mapping
Connect the tool to the organization's identity provider. Superset supports database, LDAP and OAuth2 authentication through Flask-AppBuilder, and can map LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. For Metabase, check the plan first: SSO through SAML, JWT or OIDC, and advanced LDAP group sync require Pro or Enterprise, while Open Source and Starter support Google sign-in and LDAP. Test with an account in each role. Done means a user from each group lands in the expected role and a user outside the groups is refused.
Connect warehouses with read-only accounts
Add each data source using the driver for that engine. Superset connects to any SQL datastore that has a Python DB-API driver and SQLAlchemy dialect, so confirm the driver is installed in the image before the connection is created. Use the read-only accounts from the first step, and confirm which schemas each account can see. Run a test query from the tool for each source. Done means every source returns expected results, and a sample of row counts matches a direct query run by the data owner.
Configure caching and workers if alerts are needed
If the team needs scheduled reports, alerts, async queries or dashboard thumbnails, plan the optional caching layer and Celery worker and beat processes. Superset's architecture documentation says these features require those components, and most installations use Redis and Celery for them. Check how the platform team will monitor the queue and restart failed workers. Done means a test alert runs on schedule, the worker logs show it completed, and the team knows which component to restart when it fails.
Back up before every upgrade
Before any version change, take a backup of the metadata database and keep a copy of the configuration and secret key. Metabase's upgrade docs recommend backing up the application database first, and note that migrations run automatically on startup. For Superset, the upgrade docs say to back up the metadata database and then run the database upgrade and init commands. Done means a restore has been tested once on a non-production copy, and the backup timestamp and version are recorded in the change log.
Test upgrades in staging first
Run every upgrade in a staging environment built from the production configuration and a recent metadata copy. For Superset, read UPDATING.md for breaking changes between the current and target versions. For Metabase, follow the upgrade guide, reduce a clustered deployment to a single node for major upgrades, and upgrade release by release from versions older than 40. Check the version support page to plan which release is current. Done means the staging run completes, dashboards and alerts behave as expected, and the change is approved by the data owner before production.
Evidence auditors and data owners ask for
A self-hosted BI stack creates its own evidence trail, and auditors and data owners will ask for it in the same few forms. The cards below cover the records that show where data sits, who can see what, how the platform is restored and changed, and which licenses apply. DeployOpen prepares this evidence, but independent auditors issue any opinion on it.
Architecture diagram showing data location
Draw where the BI application, its metadata database, any cache and worker processes, and each source warehouse run, with network boundaries and the region or data center for each. Auditors use this to confirm that query results and cached data stay inside the approved environment. For Apache Superset, include the metadata database because it holds dashboard definitions, database connection settings and user records. Confirm whether any component sends telemetry or uses external services, and record the answer.
Identity and role mapping records
Keep a written map of how identity provider groups become BI roles, for example through the AUTH_ROLES_MAPPING setting in Superset or group sync in Metabase. Record which sign-in methods are enabled and which plan or edition supplies them. Reviewers will test whether a leaver loses access and whether group membership changes flow through. Store the map under version control so every change has an author and a date.
Row-level rule configuration records
Document each rule that limits which rows or columns a user can see, the table it applies to, the group it targets, and the test user used to verify it. Row-level permissions are a paid feature in Metabase, so confirm the plan before relying on it. Data owners will ask for proof that rules were tested with at least one account from each restricted group, not only that the rule exists. Export the rule definitions and keep dated test results beside them.
Backup and restore test records
A backup is only evidence once a restore has been run. Record the metadata database backup schedule, where copies are stored, who can access them, and the date of the last restore into a separate environment. For Metabase, include the application database backup taken before any upgrade. Keep the restore output and any errors so the test can be repeated during an assessment.
Upgrade and change logs
Keep a dated log of each platform upgrade, the version moved from and to, the staging test results, and the backup taken beforehand. For Superset, record the UPDATING.md items reviewed and the commands run during the upgrade. Pair this with a change log for configuration edits such as secret key rotation, so reviewers can match changes to approvals. Confirm your own change window and approval process, because the log only proves what your process requires.
License inventory for open core components
List each BI component with its license and any separate enterprise or commercial directory in use. Metabase, for example, combines AGPL-3.0 code with commercial code under its enterprise directory, and Lightdash splits MIT code from an ee directory under a separate license. Record which edition or image is deployed, because the open-source and enterprise images are distinct. Legal teams need this list to judge obligations for internal use and for any embedding in customer-facing products.
Questions buyers ask before hiring help
What drives the cost of moving QuickSight to a self-hosted BI tool?
The cost depends on the work involved more than on the software, which is free to download under open-source licenses. Cost components include the infrastructure that runs the BI tool and its metadata database, any cache and worker processes you enable for scheduled reports and async queries, the engineering time to rebuild dashboards and datasets, identity integration, and ongoing operations. One-time costs cover design, connection setup and migration. Recurring costs cover hosting, monitoring, backups and upgrades. The main levers are how many dashboards you rebuild, how many data sources you connect, and whether you need paid features. Ask any provider for a written quote that separates these components.
How long does a QuickSight to Superset or Metabase move take?
Duration depends on the number of dashboards, datasets and reader groups, the complexity of row-level rules, and how many data sources must be reconnected. Work typically runs in phases: inventory, a pilot with a few dashboards, rebuild, identity setup, parallel running and cutover. Teams with heavy use of SPICE or many calculated fields usually need more time to redesign queries and caching. Ask for a timeline tied to a written scope, with the dashboards in scope listed by name. Any timeline given before the inventory is complete should be treated as provisional.
What does our team need to provide before an engagement starts?
Your team needs to provide access and decisions, not just a list of requirements. Typical inputs are:
- Read access to the QuickSight account, including an asset bundle export of dashboards, analyses and datasets for reference
- Network paths and read-only database credentials for the warehouses that Superset or Metabase will query
- A named owner for each dashboard, the reader groups in use, and the row-level access rules
- Your identity provider details for SSO, and the hosting environment, such as a VM, Kubernetes cluster or on-premises network
- A decision on backup, retention and who approves production changes
Missing items usually show up as delays in the pilot phase.
Can our own team run a self-hosted Superset or Metabase without outside help?
Yes, a team with container, database and identity skills can run either tool, and both are published under open-source licenses with documented installation paths. Apache Superset is Apache-2.0 with no paid edition, while Metabase's free Open Source edition is self-hosted with unlimited users and dashboards. The harder part is ongoing operation: running a PostgreSQL or MySQL metadata database, managing secrets, handling worker processes if you need alerts, and planning upgrades. Consider whether your team will own those tasks after go-live. A fixed-scope engagement can cover the build and handover, while a retainer covers continued upgrades and support.
Which Metabase plan do we need for SSO and row-level permissions?
According to the Metabase pricing page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics are included in the Pro and Enterprise plans, not in Open Source or Starter. Starter is listed at $100 per month, or $90 per month billed yearly, with the first 5 users included, and Pro at $575 per month, or $517.50 per month billed yearly, with the first 10 users included. Additional users cost $6 per month on Starter and $12 per month on Pro. Enterprise is priced by quote starting at $20,000 per year. Confirm current figures on the pricing page before budgeting, because plan terms can change. Also check whether your identity provider needs SAML or SCIM, which the pricing page places in Pro or Enterprise.
How are Superset and Metabase upgrades handled after go-live?
Upgrades follow each project's documented process, and the work is planned rather than automatic for Superset. For Apache Superset, the upgrade documentation calls for backing up the metadata database, running superset db upgrade and superset init, testing in staging first, and checking UPDATING.md for breaking changes. For Metabase, application database migrations run automatically, so the documentation recommends backing up the application database first, reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading release by release from versions older than 40. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months. Ask any provider how upgrades are scheduled, tested and billed, and whether they are included in a retainer.
What risks should we check before choosing Superset or Metabase?
Start with the authentication and secret handling, because Superset requires a user-specified SECRET_KEY to start and both tools store credentials for your data sources. Check which connectors your warehouses need, and whether the required driver is available for Superset's SQLAlchemy dialects. Confirm that the metadata database meets the supported versions listed in the configuration documentation, and avoid SQLite or the Docker Compose PostgreSQL container for production. Review the license terms for any enterprise features you plan to use, since Metabase uses a separate commercial license for its enterprise code. Finally, confirm the sizing of caching and worker components if you need scheduled alerts.
Does a migration help with data residency or air-gapped requirements?
A self-hosted BI tool keeps query traffic and dashboard metadata inside the network you choose, which is the main reason teams move off a service hosted by a cloud provider. Superset and the Metabase open-source edition can run on-premises, in another cloud or inside a customer environment. Metabase documents air-gapped deployment only on its Enterprise plan, so confirm that requirement before you select a tier. Whether a particular setup satisfies a residency or compliance obligation is a determination for your own assessors. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen deploys BI inside your environment
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted BI platforms inside your own cloud accounts, data centers or air-gapped networks. For a move away from Amazon QuickSight, that means placing Apache Superset or Metabase next to your data, connecting it to your non-AWS sources, and handing your team a stack it can operate.
How we scope
- We agree scope, deliverables and timelines in writing before any work starts.
- The written scope lists which QuickSight dashboards, datasets and reader groups are in and out.
- We confirm which warehouses, databases and identity providers the new BI stack must reach.
How we build
- We deploy Superset or Metabase with PostgreSQL or MySQL as the application database, not the default embedded database.
- We configure SSO through your identity provider and map groups to roles, then test access.
- We test connections, row-level rules and caching against representative data before cutover.
How we hand over
- We document the architecture, configuration, backup steps and the upgrade runbook your team will follow.
- We walk your administrators through backups, secret rotation and upgrades in staging first.
- We provide the rebuild inventory mapping each source QuickSight asset to its replacement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover version upgrades, backup verification and security testing of the BI platform.
- Confirm response expectations and upgrade scope in the written retainer before go-live.
