Migrate from Amazon QuickSight to Metabase

Migrating from Amazon QuickSight to Metabase when readers do most of the work

For a QuickSight estate where most users only read dashboards, the move to self-hosted Metabase is mainly a rebuild of questions and dashboards on the same databases, with identity and row-level access as the main design points. QuickSight SPICE datasets, analyses and dashboards do not transfer to Metabase as data or as working objects. The asset bundle export described elsewhere on this site gives you JSON or CloudFormation definitions to use as a rebuild specification, but nothing in it loads into Metabase directly. Plan the work as recreating each reader-facing dashboard as Metabase questions and dashboards, then pointing those questions at the warehouse or database that QuickSight reads from today, so the numbers can be checked side by side. In most organizations an internal platform or data team does this work, sometimes with an implementation partner for the Metabase deployment, identity wiring or hardening. Effort is driven less by the number of charts than by how many distinct data definitions sit behind them, how much logic lives in SPICE calculated fields rather than in the warehouse, and how many reader groups need different row-level views. Confirm with your own inventory which of these three drivers dominates before you estimate duration. Risk concentrates in metric definitions that were built inside QuickSight and in access rules that were applied per dataset.

Identity and access are where the design choices matter most. Metabase's open source and Starter plans support Google sign-in and LDAP, while SAML, OIDC, JWT, SCIM provisioning and advanced LDAP group sync require the Pro or Enterprise plan according to Metabase's people and groups documentation. Row and column level permissions are also limited to Pro and Enterprise on the pricing page, so if your QuickSight rules depend on row-level filtering per reader group, the Pro plan is the first tier to confirm against your requirements. Map each QuickSight reader group to a Metabase group, decide which group sets the row-level rule, and test that a reader in one group cannot see another group's rows before any dashboard is shared. Confirm current plan entitlements directly on the pricing page at the time of purchase.

Which QuickSight capabilities map to Metabase and which need rework

This table compares the main QuickSight capabilities a reader team relies on with their Metabase equivalents. Each row is marked clean, needs rework or gap, so you can see where dashboards move directly and where the design needs changes. Confirm each row in your own environment and plan tier before you commit to a scope.

QuickSight capability	Metabase equivalent	Status	Notes for the migration
Dashboards	Dashboards with filters and cards	Clean	Most read-only dashboards map to Metabase dashboards. Rebuild each tile as a saved question and confirm chart types in your environment.
Analyses and visuals	Saved questions built in the query builder or native SQL	Needs rework	Analyses often combine several visuals and parameters. Split them into questions and check each calculation result against the source.
Datasets and calculated fields	Models, saved questions and SQL expressions	Needs rework	Move shared logic into models or native SQL where possible. Calculated fields that depend on SPICE behavior need separate validation.
Filters and parameters	Dashboard filters mapped to question fields	Clean	Test filter behavior on each card, since filter wiring is set per question in Metabase.
Reader groups	Metabase groups and collections	Needs rework	Map reader groups to Metabase groups, then set collection permissions. Confirm that group sync options match your identity provider setup.
Row-level security	Row and column level permissions	Gap	Requires the Pro or Enterprise plan according to the Metabase pricing page. Confirm the plan before you design rules.
Single sign-on	SSO through SAML, JWT or OIDC	Gap	SSO is included only in Pro and Enterprise. Open Source and Starter support Google sign-in and LDAP.
Usage auditing	Usage analytics and auditing	Gap	Included only in Pro and Enterprise. Confirm which audit events you need before choosing a plan.
Embedding	Metabase embedding	Needs rework	Treat embedding as a separate project with its own design and tenant isolation review. Do not assume parity without a test.
Scheduled email	Dashboard subscriptions and alerts	Needs rework	Confirm email delivery settings and recipient lists in your environment before cutover.

What exports, what gets rebuilt and what to reconnect

QuickSight content does not move to Metabase as a file import. Asset bundles give you definitions to rebuild from, Metabase reconnects directly to the same sources, and identities and groups are set up again in Metabase. The cards below separate what you can export from what you must recreate and reconfigure.

Dashboard and analysis definitions

QuickSight asset bundle export jobs produce JSON or CloudFormation definitions of dashboards, analyses and datasets. Treat these as a rebuild specification and reference, not as an import file, because Metabase does not read them. Map each visual to a Metabase question or dashboard card, and check calculated fields and filter logic by hand, since these are the parts most often simplified during a rebuild. Confirm the export covers every asset you plan to keep before you retire anything in QuickSight.

Data connections to the same sources

Metabase connects directly to the databases your readers already query, such as Athena, Redshift or other SQL sources, so the data stays where it is and no SPICE import is needed. Confirm that your specific source has a supported driver in Metabase's supported driver list, and check version, authentication method and network path from the Metabase host. Credentials for each connection should be a dedicated service account with read-only grants, stored in your secrets tooling rather than in dashboards.

Application database setup

Metabase stores questions, dashboards, users and permissions in its own application database. The embedded H2 database is for demos, so plan PostgreSQL or MySQL from the start, with backups and a tested restore. Set this up before building content, because moving later requires a one-time load-from-h2 step that must run on the same Metabase version that last wrote the H2 file. Ask whoever operates the Metabase host to confirm the backup schedule for this database.

Reader groups and identities

QuickSight reader groups do not carry over. Recreate them as Metabase groups, then decide how people sign in: Google sign-in and LDAP are available on the free and Starter editions, while SSO through JWT, OIDC or SAML, and SCIM provisioning, require the Pro or Enterprise plan. Row-level permissions also depend on Pro or Enterprise. Confirm with your identity team which provider is the source of group membership before you map any group.

Schedules, alerts and subscriptions

QuickSight email reports and alerts need to be rebuilt in Metabase as scheduled dashboard subscriptions and alerts, each with its own recipients and timing. Recipients often include people who have left or changed teams, so review the list instead of copying it. Test delivery through your mail relay from the Metabase host, and confirm that alert thresholds still reflect the business rules they were written for.

Embedded content and access

If QuickSight embedded dashboards serve customers or internal portals, Metabase embedding needs its own setup, including how the host application signs requests and which users see which data. Confirm the embedding approach and the plan that covers it on Metabase's pricing and embedding documentation before you change any production page. Test tenant isolation with real account scenarios, not only with a demo user.

The migration sequence from inventory to decommission

The sequence moves reader dashboards from QuickSight to Metabase in five controlled phases, so each group switches only after its numbers and access rules have been checked. Each phase ends with a written output that the next phase depends on.

Inventory dashboards, datasets, readers and access rules
The BI owner exports the QuickSight asset bundle to get the dashboard, analysis and dataset definitions, then records the data sources the bundle does not carry and pulls reader group membership and sharing settings from the admin console. The output is one inventory sheet that lists each dashboard, its source database, its reader groups and its row-level rules. The step is done when every dashboard has a named owner, a source and an audience, and the team confirms that no dashboard depends on a source it cannot reach from Metabase.
Provision the Metabase application database on PostgreSQL
The platform engineer deploys Metabase in your infrastructure and points its application database at PostgreSQL rather than the embedded H2 file, which Metabase ships for demos. Metabase documents PostgreSQL as the recommended production choice, and its migration guide covers moving an existing H2 file with the load-from-h2 command when a team has started on H2. The output is a running instance with a tested backup of the application database. Confirm the Metabase version against the version support page before you install it.
Pilot a small dashboard set with a few reader groups
The BI owner rebuilds a small set of representative dashboards in Metabase, connects them to the same databases QuickSight reads, and gives access to one or two reader groups. Mapping groups uses Metabase's people and groups model, and the team should confirm which group sync features their plan includes before relying on them. The output is a pilot signed off by the pilot readers, with a list of gaps in chart types, filters or permissions that the team has to close before a wider rollout.
Run both tools in parallel against agreed checks
For a defined period set by the business, both QuickSight and Metabase serve the same dashboards, and the team compares the figures for an agreed list of checks, such as totals by region, row counts after filters and the latest refresh timestamp. Differences in rounding, time zones or null handling are logged and resolved in the query, not in the reader's head. The output is a reconciliation log where every check either matches or has a documented cause and a fix. Readers keep using QuickSight until the log is clean.
Cut over one reader group at a time
The team moves each reader group to Metabase in turn, removing its QuickSight access only after its dashboards have passed the parallel run and its members have confirmed access. Row-level permissions must be verified for each group, and features that require a paid Metabase plan, such as SSO or row and column level permissions, must be in place before that group moves. The output is a cutover record per group, with the date, the owner who approved it and a rollback path back to QuickSight until the final phase.
Decommission QuickSight after confirming no dependencies
Before the QuickSight subscription and its reader and author seats are ended, the team checks that no scheduled emails, embedded pages, API consumers or downstream exports still call QuickSight, and that the asset bundles are archived for reference. Finance and procurement confirm the contract end date with AWS. The output is a signed decommission checklist showing zero active dependencies, a retained archive of the asset bundles and a final access review of Metabase groups. Back up the Metabase application database before any Metabase upgrade made during or after the migration, and follow the upgrade guidance to run migrations safely.

What drives migration cost and duration

This table lists the factors that move effort when a QuickSight estate moves to Metabase, and how each one can be kept down. Read it before scoping, because most of the cost sits in the size of the content inventory and the number of rules to rebuild, not in the Metabase installation itself.

Driver	Why it moves effort	How to keep it down
Number of dashboards and questions	Each dashboard is rebuilt by hand in Metabase's question and dashboard builder, and each tile must be checked against the QuickSight original.	Retire unused or duplicate dashboards before rebuild, using QuickSight usage data to find them.
Datasets and calculated fields	QuickSight calculated fields and dataset joins must be re-expressed as Metabase models, SQL or custom expressions, and any logic that lived only in QuickSight needs a new home.	Move shared logic into a small set of Metabase models so definitions are written once and reused.
Row-level rules	Row-level permissions are a paid feature in Metabase (Pro or Enterprise per the pricing page), so rules must be mapped, tested and tied to the right groups before cutover.	Consolidate rules into a few group-based patterns and confirm the Metabase plan before design starts.
Reader group count and mapping	Each QuickSight reader group must be mapped to a Metabase group with the correct collection and data permissions, and overlapping memberships add review time.	Export the current group list, merge groups that share the same access, and agree the mapping with data owners in writing.
Identity provider integration	SSO, SAML and SCIM provisioning require Pro or Enterprise in Metabase, and the identity setup and testing depend on the plan chosen and the existing IdP.	Confirm the target plan and the IdP setup (for example Entra ID, Okta or Keycloak) early, since plan choice changes scope.
Embedded content	Any QuickSight embedding must be re-implemented with Metabase embedding and the host application's tenant isolation, which is a development task outside the BI rebuild.	Separate embedded dashboards into their own phase and confirm whether they are in scope for this migration.
Data source count and connection type	Each database or warehouse needs a connection, credentials, network access and a check that query results match, and SPICE-cached data must be replaced by live queries or another caching approach.	Group sources by owner and environment, and document which datasets relied on SPICE refreshes.
Validation depth for the parallel run	Running both tools side by side means comparing figures for each key metric over a period, which grows with the number of reports and their business importance.	Agree a short list of business-critical metrics and tolerance rules, and limit the parallel run to those reports.

What usually goes wrong and how to prevent it

Most failed QuickSight-to-Metabase moves fail on details rather than on the tool itself: exported definitions, access rules, plan limits, the application database, upgrades and metric logic. Each card below names one risk and one check to run before cutover.

Treating the asset bundle as an import file

A QuickSight asset bundle describes dashboards, analyses and datasets in Quick Sight JSON or CloudFormation form, but it does not carry the data and Metabase cannot load it directly. Teams that expect a one-step import lose time when they find the bundle is only a reference. Use it as a rebuild specification: list each dashboard, its source dataset, filters and calculated fields, then recreate each question in Metabase and confirm the row counts match the source.

Rebuilding row-level rules untested

Row-level restrictions in QuickSight are often defined through dataset rules tied to reader groups, and it is easy to recreate them loosely in Metabase. Row and column level permissions are a paid feature, so the rules must be checked on the plan you actually run. Prevention: for each reader group, log in as a test user from that group and confirm they see only their permitted rows, and that restricted columns stay hidden in questions and exports.

Underestimating the plan for SSO

Metabase's free Open Source edition and Starter plan support Google sign-in and LDAP, but JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise. Teams that rely on an existing corporate identity provider can find the chosen plan blocks their login model after the build is finished. Before committing, confirm which identity protocol your reader groups use and map it to the plan that supports it, including group sync if reader groups are managed centrally.

Running production on the embedded H2 database

Metabase starts with an embedded H2 application database, which suits demos but holds users, questions, dashboards and permissions in a local file. Running production on it makes backups and recovery harder and complicates scaling. Set up PostgreSQL or a supported MySQL or MariaDB version as the application database before the first reader logs in. If an evaluation instance already holds work, plan a one-time load-from-h2 move, run with the same Metabase version that last wrote the file.

Upgrading across releases without a backup

Metabase runs application database migrations automatically on upgrade, and the upgrading guidance recommends backing up the application database first. Teams that stay on an old build and jump several versions face longer and riskier migrations, and a major upgrade may require reducing a cluster to one node because of a migration lock. Prevention: take and test a database backup before each upgrade, prefer a Long Term Support line where the release schedule suits you, and upgrade release by release when starting from versions older than 40.

Metric definitions drifting during parallel run

During a parallel run, QuickSight and Metabase often show different totals for the same KPI because of time zones, null handling, distinct counts, fiscal calendars or calculated fields written differently in each tool. Those gaps erode reader trust faster than any missing chart. Prevention: agree a written definition for every headline metric, store it once in the source database or a governed view where possible, and reconcile both tools on the same date range before retiring any QuickSight dashboard.

How the migration differs by starting point

A small team with a handful of dashboards and no SSO requirement can start on the free Open Source edition, which allows unlimited users and dashboards when self-hosted. The migration is mostly a rebuild of questions and dashboards against the same databases, so the sequence follows the content you need to recreate.

Plan choice: Open Source covers unlimited users and dashboards, so there is no seat cost to plan for at this stage.
Sign-in: Google sign-in and LDAP are available on the free edition, so confirm that every reader can sign in with one of those methods.
Application database: Use the embedded H2 database only for a pilot, then move to PostgreSQL before users rely on saved questions. The one-time load-from-h2 command must run with the same Metabase version that last updated the H2 file.
Groups: Map the QuickSight reader groups to a short list of Metabase groups by hand, since a small estate makes that review quick.
Scope check: Confirm that no row-level or column-level rule from QuickSight is in use, because those controls are not part of the free edition.

Confirm the sign-in methods and the absence of row-level rules before you commit to this path, because either one can change the plan you need.

Questions teams ask before moving from QuickSight to Metabase

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

The effort depends mostly on how many dashboards, datasets and reader groups you have, and on how much of the logic lives in QuickSight calculated fields, filters and row-level rules. Metabase connects to the same databases, so the data path is usually the simpler part. The larger share of work is rebuilding questions and dashboards, recreating permissions, and checking that numbers match the originals. Ask a partner to inventory these items first, because the inventory is what turns a rough estimate into a quote. Stand up a Metabase test instance on PostgreSQL alongside QuickSight so reconciliation can run before any reader is moved.

How long does the migration take, and what sets the timeline?

No fixed duration can be given without the inventory, so treat any number you see as unverified until your own dashboard count and data sources are known. The main drivers are the number of dashboards to rebuild, the number of data sources and their quality, the number of reader groups and row-level rules, and how many people must review and sign off on numbers. Parallel running, where QuickSight and Metabase show the same figures for a period, usually adds time but lowers risk. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for the timeline as part of the written scope.

Can our team do the QuickSight to Metabase move alone?

A team with SQL skills, a database administrator and someone who owns the BI content can often rebuild a small set of dashboards in-house. The work becomes harder when you must operate PostgreSQL for the Metabase application database, configure identity integration, and reconcile numbers across many dashboards. Consider the time your analysts already spend on production work, and whether anyone will own upgrades after go-live. DeployOpen can plan, implement, integrate, back up and document a self-hosted Metabase in your own infrastructure under a fixed scope, or support the in-house team through a retainer.

What do we need from our own staff during the move?

The move needs more of your people's time than your vendor's, and the right people matter more than the number of them. Data owners confirm which metrics are authoritative and sign off on reconciled results. Identity administrators map QuickSight reader groups to Metabase groups and decide how users authenticate. Database administrators provision read access and the Metabase application database. Security or compliance staff review row-level rules and access logs. Name these owners at the start, because delayed sign-off is one of the most common causes of schedule slippage.

Do QuickSight dashboards and datasets import into Metabase automatically?

No. Metabase does not import QuickSight analyses, datasets or calculated fields, so questions and dashboards must be recreated in Metabase. QuickSight asset bundle exports can serve as a reference specification that shows the datasets, joins, calculations and filters your team needs to rebuild. Metabase connects directly to the same SQL databases, so the underlying tables do not move. Your data itself is not exported with the bundle, so plan separately for any data that lives only in SPICE and confirm where the authoritative copy sits before you start.

Which Metabase plan includes SSO and row-level permissions?

SSO and row and column level permissions are included only in the Pro and Enterprise plans, according to Metabase's pricing page. The free Open Source edition and the Starter plan do not include them. Starter supports Google sign-in and LDAP, while JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise. Pro is listed at $575 per month, or $517.50 per month billed yearly, with the first 10 users included and $12 per additional user per month. Enterprise is priced by quote starting at $20,000 per year. Confirm current plan details with Metabase before you decide, because plan contents can change.

How are Metabase upgrades handled after go-live?

Upgrades are a recurring task that someone must own. Metabase runs application database migrations automatically at upgrade, so back up the application database before every upgrade. For major upgrades, the documentation recommends reducing a cluster to a single node 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. Plan a test upgrade environment and a recurring maintenance window, or agree on a retainer that covers upgrades and testing.

What does Metabase cost compared with QuickSight over time?

Metabase's free Open Source edition has no license fee, so the recurring cost is infrastructure, staff time and any paid plan you choose. QuickSight charges per user and per reader session, so its costs rise with headcount and usage. A fair comparison counts the database, the Metabase application database, compute, backups, monitoring, upgrades and support time, as well as any Pro or Enterprise subscription needed for SSO and row-level permissions. Ask for a quote that itemizes these components so you can compare them against your current QuickSight invoices.

How DeployOpen scopes and runs a QuickSight to Metabase migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted Metabase inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For a QuickSight move, the work usually starts with an inventory of which readers, dashboards and datasets are in use, which databases they read from, and where the Metabase application database will live. The written scope then defines which dashboards are rebuilt, which reader groups are mapped to Metabase groups, which identity provider is connected, and what evidence is delivered at the end. Your team should confirm early which Metabase edition is needed, because SSO and row and column level permissions are part of the paid Pro and Enterprise plans, not the free Open Source edition.

Most engagements are fixed-scope. 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, which DeployOpen does not maintain. Cost drivers you should expect to see itemized include the number of dashboards and questions to rebuild, the number of databases and connection types, the identity integration, the hosting and backup design, the Metabase subscription tier if you choose a paid plan, and the time your own staff spend on validation. Ask for each item to be listed separately, and ask which items are one-time and which recur, such as hosting, Metabase plan fees and upgrades.

After go-live, ongoing support, upgrades and continuous testing are available as retainers. This matters for Metabase because upgrades run application database migrations automatically, and the vendor recommends backing up the application database first and reducing a cluster to a single node for major upgrades. Agree in the written scope who performs upgrades, who signs off on the test results, who owns the backup restore test, and how a rollback would run. DeployOpen prepares systems, controls and documentation for your compliance assessments, but independent auditors and certification bodies issue any audit report or attestation.