When QuickSight or Metabase fits your BI team
The decision usually starts with one of three situations: a QuickSight renewal that brings a per-user or per-session cost increase, a data residency rule that keeps data inside your own network, or business users who want answers to their own questions without writing SQL. QuickSight fits best when your data already lives in AWS, your analysts are comfortable with AWS services, and you prefer AWS to run the servers, upgrades and scaling. It is a managed service, so the operating work sits with AWS and your team mainly manages users, datasets and permissions.
Metabase fits when you want the BI layer under your own control. Its query builder lets non-SQL users filter, group and chart data through a point-and-click interface, and the free Open Source edition covers unlimited users and dashboards when you run it yourself. That covers many core reporting needs without a license fee. The trade-off is that your team operates the application: a Java JAR or container, a PostgreSQL application database, backups, and upgrades. Metabase's documentation recommends backing up the application database before each upgrade, and advises reducing a cluster to a single node for major upgrades because of a migration lock. Confirm that your platform team can own that routine before you commit.
Three questions should drive the choice. First, do you need SSO, row-level permissions or column-level permissions? Under Metabase's pricing page, those features sit in the Pro and Enterprise plans rather than Open Source or Starter, so you need current plan pricing for your user count before you assume free is enough. Second, where must the data and the BI metadata live? If the answer is your own data center or an air-gapped network, check which plans support that deployment, since the pricing page limits air-gapped deployment to Enterprise. Third, can your team run a PostgreSQL-backed application with a patching schedule? If not, a managed option may be the safer path even when the self-hosted license cost looks lower.
Which option fits which scenario
This table maps common decision scenarios to the better fit between Amazon QuickSight and self-hosted Metabase, with the reason for each. Read it against your plan requirements, since Metabase's SSO and row-level permissions depend on the paid tier.
| Scenario | Better fit | Reason |
|---|---|---|
| Business users build questions without SQL | Metabase | The query builder lets non-SQL users filter, group and chart data, and the free Open Source edition has unlimited users and dashboards. |
| Data must stay on premises or in a non-AWS cloud | Metabase | QuickSight is an AWS-hosted managed service, while Metabase runs as a JAR or Docker image inside your own infrastructure. |
| Single sign-on with SAML or OIDC | Metabase Pro or Enterprise | JWT, OIDC, SAML and SCIM require Pro or Enterprise. Open Source and Starter support Google sign-in and LDAP only. |
| Row-level security for different reader groups | Metabase Pro or Enterprise | Row and column level permissions are included only in Pro and Enterprise, so confirm this need before choosing Starter. |
| Embedded analytics for external customers | Confirm with a proof of concept | Metabase embedding is documented, but tenant isolation and plan fit depend on your design. Check the embedding docs and pricing before committing. |
| AWS-only estate with no spare ops capacity | QuickSight, unless you accept upkeep | Self-hosting means you run the server, PostgreSQL application database, backups and upgrades. Assess whether your team can carry that work. |
| Predictable cost across a growing reader base | Metabase, after plan review | Open Source has no per-user fee, but Pro is priced per month with users included and extra users billed. Ask for a quote based on your user count. |
How the query builder and question model differ
QuickSight separates the people who build content from the people who consume it. Authors create analyses and datasets in the console and are licensed as a seat, while readers open published dashboards under a different billing model. For a non-technical user, the key question is which role they hold and whether they ever need to change a chart, because that answer drives both the user experience and the cost. Confirm current role names and billing terms with AWS before you model either.
- Authors build content: Business users who need to change a visual, add a filter or create a new chart usually need an author role, which typically carries the larger per-seat cost.
- Readers consume dashboards: Readers apply filters to published dashboards and are the group most often billed per session or in packs, so confirm which model applies to your reader count.
- Questions come from prepared fields: Users work from datasets and fields the data team has defined, so self-service depends on how well those datasets are modeled.
- Permissions attach to published assets: Access is granted to dashboards and folders, so map who can edit and who can only view before the pilot begins.
Check whether your pilot group will need author access, since that answer changes the cost model more than any other single factor.
QuickSight can import data into SPICE, its in-memory engine, or query the source database directly. SPICE gives fast interactive visuals but adds storage and refresh schedules, so the numbers a reader sees are only as current as the last refresh. Direct query keeps the data in the source, so every filter depends on the performance of that database under concurrent use. For a non-technical user, the difference usually shows up as stale figures or slow filters, not as an error message.
- SPICE import: Data is copied into QuickSight and refreshed on a schedule, so responses are quick but the figures can lag behind the source.
- Direct query: Each interaction runs against the database, so response time depends on warehouse capacity and how many users query at once.
- Storage and refresh costs: SPICE capacity and refresh activity are separate cost items to request in any quote.
- Migration consequence: SPICE contents are not carried into Metabase, so Metabase must connect to the source databases and either query them directly or rely on its own caching choices.
Run a dashboard with a business-hours refresh and a filter-heavy session before deciding which data mode your team needs.
Metabase's query builder lets a user choose a table, add filters, summarize a metric, group by a dimension and pick a visualization without writing SQL. A question built this way can be saved, reused on dashboards and shared with groups. The scope of what a user can see depends on the database connection and the permissions an administrator configures, so the builder is only as clear as the metadata behind it.
- Guided steps: Users chain filter, summarize and group steps in an editor that shows each stage of the question.
- Saved questions: A saved question keeps its logic, so the same definition can appear on several dashboards without being rebuilt.
- Field and table metadata: Administrators set display names, descriptions and field types, which helps users find the right column without asking an analyst.
- Row and column restrictions: According to the Metabase pricing page, row and column level permissions are included in the Pro and Enterprise plans, so Open Source deployments need another control for sensitive fields.
Confirm which metric definitions your users will reuse and whether the query builder can express them without a native query.
Metabase also includes a native SQL editor for questions the query builder cannot express, such as complex joins, window functions or custom calculations. Native questions can be saved, filtered with variables and placed on dashboards alongside builder questions. The trade-off is that the person writing SQL needs database access and an understanding of the schema, so this is the point where non-technical users usually depend on an analyst.
- Analyst-written questions: Analysts write native queries that business users then open, filter or copy into their own dashboards.
- Variables and dashboard filters: Dashboard filters can feed native questions, which lets readers adjust results without editing the SQL. Confirm which variable types your Metabase version supports.
- Dashboard composition: Dashboards combine builder and native questions under shared filters and can be shared with specific groups.
- Database access: Users who write native SQL need query permissions on the underlying connection, and that control should be tested during the pilot.
Identify which current dashboards rely on calculations the query builder cannot express, since those are the first items to rebuild and verify.
A non-technical user is best served by the model that lets them answer a new question without waiting for an analyst, and each product meets that need under different conditions. QuickSight tends to fit when the data team publishes governed datasets and most readers only need filters on finished dashboards. Metabase tends to fit when business users need to reshape a question themselves in the query builder. Only a pilot with real users and your own data can show which condition applies to your organization.
- Unassisted questions: Observe whether a business user can answer a common question in each tool without help from the data team.
- Drill and filter behavior: Test whether drilling into a chart keeps the underlying definition intact and whether filters behave the same way across dashboards.
- Metric consistency: Compare a key metric built in each tool against the figure in your finance report, using the same date range.
- Freshness expectations: Confirm how often the data must refresh and whether SPICE or direct query meets that requirement.
- Access boundaries: Confirm who can edit and who can only view, and decide whether row-level restrictions need a paid Metabase plan or another control.
Record the results with the same users and the same dataset in both tools, because the outcome depends on the people and the data as much as on the product.
Capabilities, licensing and identity compared
This table compares licensing, open-source status, editions, identity options, permissions, the application database and deployment model for QuickSight and Metabase. Metabase rows show which plan unlocks each feature, while QuickSight rows flag what to confirm with AWS before deciding.
| Capability | Amazon QuickSight | Metabase |
|---|---|---|
| Licensing model | Per user or per reader session under the AWS service model; confirm current rates with AWS | Free Open Source edition, plus Starter, Pro and Enterprise plans; Enterprise quoted from $20,000 per year |
| Open-source status | Proprietary AWS managed service with no open-source code | Open core: code outside the enterprise directory is AGPL-3.0, enterprise code is under the Metabase Commercial License |
| Editions | Confirm current tiers and feature differences in AWS documentation | Open Source, Starter, Pro and Enterprise, with a separate open-source Docker image |
| SSO and LDAP by plan | Confirm supported identity providers and SSO options with AWS | Google sign-in and LDAP in Open Source and Starter; SAML, OIDC, JWT and SCIM need Pro or Enterprise |
| Row and column permissions | Confirm row-level and column-level controls in current AWS documentation | Row and column level permissions only in Pro and Enterprise |
| Application database | AWS-managed; you do not choose the metadata store | H2 for demos; PostgreSQL recommended for production; MySQL 8.4.0 or MariaDB 10.6.0 and later also supported |
| Deployment model | Hosted in AWS regions; confirm any on-premises or air-gapped option | Self-hosted in your infrastructure; air-gapped deployment only on Enterprise |
| Usage analytics and auditing | Confirm audit and usage reporting features with AWS | Included only in Pro and Enterprise plans |
Where the data and metadata live
Where QuickSight and Metabase run determines who controls the database connections, the dashboard metadata and the audit trail. The cards below cover the hosting model, the identity path, and the evidence an assessor will ask for, so the decision rests on your own environment rather than on a vendor summary.
Hosting model and data path
QuickSight is an AWS-hosted managed service, so the BI control plane runs in AWS regions chosen by AWS. Metabase runs as a JAR or Docker image in your own accounts or data centers, next to the warehouse. Map each query path end to end: which network segment the BI service reaches, whether results are cached outside your boundary, and whether SPICE copies of data sit in a region you did not choose.
Application database location
Metabase stores questions, dashboards, users and permissions in an application database. It ships with an embedded H2 database for demos and recommends PostgreSQL for production, with MySQL and MariaDB also supported. Your team owns that database, its backups and its encryption. Confirm where it runs, who holds the credentials, and how it is restored, because it holds the metadata an assessor will request.
Identity integration and sign-in
QuickSight authenticates users through IAM Identity Center, AWS Identity and Access Management, or its own user store, depending on the setup. Metabase open source and Starter support Google sign-in and LDAP. JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise. If your directory is Okta, Entra ID or Keycloak, confirm which Metabase plan you need before you design group mapping.
Row-level access and tenant rules
Row-level and column-level permissions decide what each reader sees inside the same dataset. In Metabase, these controls sit in the Pro and Enterprise plans, not in Open Source or Starter. Write down where each rule is enforced, whether in the database through views or policies, or in the BI layer, and test that a restricted user cannot reach the data by an alternate path.
Audit logs and evidence
Access logs, export history and permission changes are the records an assessor samples. Ask the vendor which audit events QuickSight writes to CloudTrail and what it keeps in its own logs, then compare with what your self-hosted Metabase writes to its own logs and your central log platform. Decide retention and who can read the logs before the migration.
Compliance evidence ownership
Controls and evidence are prepared by your organization. DeployOpen can prepare systems, configurations and documentation for a compliance assessment, but it does not issue audit reports, attestations or certifications. The vendor's own attestations cover the vendor's service only. Independent auditors and certification bodies decide whether your controls meet the requirement, so confirm the scope with them before you rely on any vendor document.
What moving from QuickSight to Metabase involves
The sequence moves reader-facing questions and dashboards from QuickSight into a self-hosted Metabase on PostgreSQL, with the same databases, a confirmed plan for SSO and row-level rules, and a parallel period before users are switched over. The main output is a set of recreated questions and dashboards that business users have checked against QuickSight numbers.
Inventory dashboards, datasets and reader groups
Start by listing every QuickSight dashboard, analysis and dataset, marking which ones are read by business users and which are used for authoring. Export the asset bundle to get the definitions of datasets, calculated fields and filters, which serve as a rebuild reference. Record who reads each dashboard and which reader groups and row-level rules apply. The step is done when every dashboard in use has an owner, a list of underlying datasets and a named reader group. Note that the bundle contains definitions but not data, so the data itself must come from the source databases.
Confirm database connections and access
Verify that each source database behind the QuickSight datasets can be reached from the Metabase host with a read-only account. Check the network path, TLS settings and whether the service account can see the same schemas and tables that QuickSight uses. Where a dataset relied on SPICE snapshots, confirm which live tables should replace it and whether the database can handle direct queries from dashboards. The step is done when a test query from Metabase returns the same row counts as the source for a sample of key tables.
Choose the Metabase plan for SSO and row-level rules
Compare the reader requirements with the Metabase plans. The free Open Source edition is self-hosted with unlimited users and dashboards, but SSO, row and column level permissions and usage analytics appear only in the Pro and Enterprise plans on the pricing page, and Starter does not include them. If your identity provider needs SAML, OIDC or SCIM, confirm that the chosen plan covers it. Ask Metabase for a written quote for the plan that matches your user count and permissions. The step is done when the plan decision is documented against each requirement from the inventory.
Deploy Metabase with PostgreSQL as the application database
Install Metabase on infrastructure you control, using the open-source image or the commercial image if the chosen plan requires it. Configure PostgreSQL as the application database rather than the embedded H2 database, which Metabase provides for demos and does not recommend for production. Set up backups of the application database before any later upgrade, since Metabase runs its migrations automatically. The step is done when Metabase starts against PostgreSQL, a backup has been restored into a test environment, and an administrator can log in.
Recreate questions and dashboards in Metabase
Rebuild each in-scope dashboard using the Metabase query builder for business questions, and use SQL for logic that the builder cannot express. Reproduce calculated fields, filters and date ranges from the bundle definitions, and apply the same data model to each question. Assign each dashboard to a collection that matches its audience. Expect this to be the largest piece of work, because QuickSight definitions are not automatically converted into Metabase questions. The step is done when each dashboard has an owner and its figures match the QuickSight version for an agreed set of reference values.
Migrate users and map reader groups
Create Metabase groups that mirror the QuickSight reader groups, then apply group-level permissions to collections and data. If the plan includes SSO or directory sync, connect the identity provider so that group membership follows the directory. If row-level permissions are required, configure them on the groups and test each rule with a representative user from every group. The step is done when a sample of users from each group can see exactly the dashboards and rows they had in QuickSight and nothing beyond that.
Run parallel reports before switching over
Keep QuickSight running while a set of business users read the same reports in Metabase. Compare results for the agreed reference figures on a fixed schedule and log every difference, including those caused by time zones, rounding and filter defaults. Resolve each difference with the report owner before moving on. The step is done when the owners sign off the reconciled figures and no open differences remain on the reports in scope.
Cut over and retire QuickSight access
Announce the switch to readers, point links, embedded pages and scheduled deliveries at Metabase, and make the QuickSight dashboards read-only. Confirm the backup and monitoring routines for the Metabase host are running, and record the plan for upgrades, including reviewing Metabase version support before each upgrade. Retire QuickSight subscriptions and reader seats only after the agreed notice period and once the sign-off is complete. The step is done when all in-scope readers use Metabase and the QuickSight subscription is confirmed as ended in writing with the account owner.
How to run self-hosted Metabase on PostgreSQL
The first operating decision is to move Metabase off its embedded H2 application database before users depend on it. Metabase ships with H2 for demos, and it recommends PostgreSQL for production, so the application database (saved questions, dashboards, users and permissions) should live in PostgreSQL from the start. Metabase documents a one-time load-from-h2 command that copies an existing H2 file into PostgreSQL or MySQL. Run it with the same Metabase version that last wrote the H2 file, or the copy can fail. Keep the H2 file as a fallback until you have confirmed that questions, collections and group permissions match in the new database. Confirm the supported PostgreSQL and MySQL versions in the current application database documentation before you provision the server.
Plan backups and upgrades as one routine. Metabase runs application database migrations automatically when a newer version starts, so an upgrade changes the database schema without a separate step. Back up the application database before every upgrade, and test the upgrade against a copy first. For major upgrades, the upgrading guide recommends reducing a cluster to a single node because of a migration lock, so schedule a short window in which only one instance serves users. Upgrade one release at a time when you are coming from a version older than 40. Your Metabase version and its database backup should match each time, so record both in your change log.
Version support determines how often this routine repeats. Metabase LTS releases are supported for 14 months, while non-LTS releases usually reach end of life after about 2 months. Metabase 64 is an LTS release published on 16 September 2026, with end of life on 1 December 2027. Metabase 65 was released on 12 October 2026 as a non-LTS release. Choose the LTS line for an internal reporting tool that business users rely on, and confirm the current end-of-life dates on the version support page before you set a calendar. Staffing is the recurring cost here: someone must own the upgrade calendar, the backup jobs, the PostgreSQL patching and the on-call response, and that effort does not drop to zero because the software is free.
Questions buyers ask before switching to Metabase
What does it cost to switch from QuickSight to a self-hosted Metabase?
The cost is the sum of components you pay for, and only some of them are license fees. The Open Source edition itself is free to self-host with unlimited users and dashboards, so the recurring costs are infrastructure (an application server, a PostgreSQL database for Metabase's own metadata, backups and monitoring), the staff time to operate it, and any paid Metabase plan you choose. The one-time costs are the migration work: recreating questions and dashboards, reconnecting data sources, and rebuilding access rules. Ask any implementation partner for a quote built from a written scope that lists each of these components separately, so you can compare it with your current QuickSight invoices line by line, including Author, Reader and session charges.
How long does a QuickSight to Metabase migration take?
The duration depends on how many dashboards and datasets you have, how much of your logic lives in QuickSight calculated fields and SPICE datasets, how many data sources must be reconnected, and how much access control must be rebuilt. Teams whose readers mostly consume dashboards usually have a smaller job than teams with many authored analyses. Two factors often add time: rebuilding row-level rules, which depend on your plan choice, and validating that numbers match the source figures during parallel running. Your asset bundle export from QuickSight gives you an inventory to size the work. Ask for a timeline tied to that inventory rather than to a generic estimate, and confirm which items are in scope.
Can our own team migrate to Metabase without outside help?
Many teams can do the core work in-house if they have someone comfortable with SQL, a database administrator who can set up PostgreSQL, and an engineer who can run a container or JAR-based deployment. The harder parts are usually the operating model: setting up identity integration, defining groups and permissions that mirror QuickSight reader groups, backing up the application database, and planning upgrades. Metabase's documentation covers each of these steps. If your team lacks capacity in any of these areas, a fixed-scope engagement from DeployOpen can cover planning, implementation, hardening, backups and documentation in your own infrastructure, with the scope and deliverables agreed in writing before work starts.
Which Metabase plan is needed for SSO and row-level permissions?
Row and column level permissions, and SSO, are included 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. Google sign-in and LDAP are available on Open Source and Starter, while JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise. If your QuickSight setup relies on row-level rules or federated sign-in, plan for Pro at minimum. The Pro price is listed as $575 per month, or $517.50 per month billed yearly, with the first 10 users included and $12 per additional user per month. Confirm current prices on the pricing page before budgeting, because plan terms can change.
How do upgrades and LTS support affect the staff we need?
Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months. Choosing LTS releases lowers how often you must upgrade, but you still need a routine. Metabase runs application database migrations automatically, so each upgrade should start with a backup of the application database. For major upgrades, the documentation recommends reducing a cluster to a single node because of a migration lock, and upgrading release by release if you are coming from versions older than 40. Budget recurring staff time for these upgrades, testing dashboards afterward, and tracking end-of-life dates on Metabase's version support page.
Is the free Metabase Open Source edition enough for our organization?
It depends on what you need from identity, access control and support. The Open Source edition is free to self-host, with unlimited users and dashboards, which suits teams whose readers do not need SSO or row-level filtering and who can support themselves. It does not include SSO, row and column level permissions, multi-tenant data segregation, or usage analytics and auditing. Also check the Metabase open core split: the open-source Docker image is separate from the enterprise image, and only the Enterprise plan offers air-gapped deployment. If any of those requirements apply, compare the Pro or Enterprise plan cost against the engineering time needed to build the missing controls yourself.
Where does the Metabase application database need to live?
Metabase stores its own metadata, including questions, dashboards and users, in an application database. It ships with an embedded H2 database intended for demos, and Metabase recommends PostgreSQL for production, with MySQL 8.4.0 or MariaDB 10.6.0 and later also supported. If you start on H2, Metabase documents a one-time load-from-h2 command to move to PostgreSQL or MySQL, which must be run with the same Metabase version that last updated the H2 file. Plan for this database to be backed up, monitored and included in your disaster recovery design, since it holds everything your team builds in Metabase.
Risks to plan for in a Metabase rollout
A move from QuickSight to Metabase shifts several decisions to your team: which plan you pay for, how upgrades are run, where the application database lives, and who watches the system after launch. The cards below cover the risks that most often surprise teams after a rollout starts, with the checks to make before you commit.
Plan tier drift for SSO and row rules
Open Source and Starter cover Google sign-in and LDAP, but SSO through JWT, OIDC or SAML, and row and column level permissions, are only in Pro and Enterprise. Teams often build a pilot on the free edition, then find that the access model they need for reader groups depends on a higher tier. Before rollout, list every authentication method and every data access rule your QuickSight setup enforces today, then confirm which Metabase plan covers each one using the current pricing page. Get the quote in writing, since Enterprise pricing is set by quote.
Upgrade migrations and single-node windows
Metabase runs application database migrations automatically on upgrade, so each version change touches live metadata. The upgrade guidance recommends backing up the application database first, reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading one release at a time when starting from a version older than 40. Plan a maintenance window for each major upgrade, test the upgrade on a copy of the application database, and schedule upgrades against the support calendar so you do not fall off a supported line.
H2 to PostgreSQL version matching
Metabase ships with an embedded H2 application database that is suitable for demos but not for production. The one-time load-from-h2 command moves that data to PostgreSQL or MySQL, and it must run with the same Metabase version that last updated the H2 file. A mismatch can leave questions, dashboards or permission settings incomplete. Before cutover, record the exact Metabase version that wrote the H2 file, confirm the target database is PostgreSQL or MySQL with utf8mb4 where required, and verify saved questions, collections and groups in the new instance before users are switched over.
Query performance on warehouses
QuickSight often reads from SPICE, an in-memory store that keeps dashboards responsive without hitting the warehouse on each view. Metabase sends queries to the source database at view time, so dashboard speed depends on warehouse capacity, indexes, query design and caching settings. Business users who build questions with the query builder can generate expensive joins without noticing. Run your heaviest existing QuickSight dashboards against the same warehouse in a pilot, measure load times with real user counts, and agree with the data platform team on which tables need summary models or aggregated views.
Embedding tenant isolation
If you plan to embed Metabase in a customer-facing application, the host application must enforce which data each tenant can see. Embedding changes the access model compared with an internal reader group, and a misconfigured signed embed or permission scope can expose another customer's rows. Review the embedding introduction and the plan requirements for each feature you need, then test isolation with accounts from at least two tenants before launch. Document who owns the signing secret, how it is rotated, and how the host app passes tenant identity into each embed request.
Backups and monitoring after go-live
After launch, the application database holds saved questions, dashboards, permission groups and subscription settings. Those objects need regular backups tested by restore, and the Metabase instance needs monitoring for availability, query errors and database connection health. These tasks belong to a named owner in your platform or data team, and they recur for as long as the system runs. Assign the owner, define the backup schedule and retention with your security team, and confirm who responds when a scheduled report or dashboard fails. Ask any implementation partner to state these operating tasks in the written scope.
What a DeployOpen engagement covers for Metabase
A fixed-scope engagement is the usual way to move from QuickSight to a self-hosted Metabase, and the first deliverable is a written fit assessment. DeployOpen compares your current QuickSight reader groups, data sources and row-level rules against what Metabase's open source edition provides, and flags where a paid plan is needed. The features most likely to drive that decision are SSO, row and column level permissions and usage auditing, which the Metabase pricing page places in the Pro and Enterprise plans. Scope, deliverables and timelines are agreed in writing before any work starts, and a price follows from that written scope rather than from a list.
The core build covers deploying Metabase in your own infrastructure with PostgreSQL as the application database, since Metabase recommends PostgreSQL for production over its embedded H2 database. The work includes network placement, TLS, backups of the application database, a tested upgrade procedure, and the hardening settings your security team needs to review. If you are moving an existing H2 instance, the load-from-h2 step must be run with the same Metabase version that last wrote the H2 file, so confirm that version before scheduling the cutover. Identity integration is scoped separately: confirm with your IdP team which protocol you will use, because Google sign-in and LDAP are available on the open source and Starter plans, while JWT, OIDC, SAML and SCIM require Pro or Enterprise.
Migration and handover close the engagement. DeployOpen can recreate priority dashboards and questions, map reader groups to Metabase groups, and connect Metabase to the same databases your QuickSight datasets read from, so no data is copied out of your environment. Handover includes runbooks for upgrades, backup restores and user administration, plus a list of decisions your team still owns, such as which Metabase version track to follow. Ask any provider to put in writing who performs each task, what is verified before sign-off, and what ongoing support, if any, is included after go-live.
How DeployOpen helps you evaluate and move to Metabase
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Amazon QuickSight vs Metabase, that means testing the business questions your readers ask against a Metabase instance you control before any dashboard is rebuilt.
How we scope
- We inventory the QuickSight dashboards, datasets and reader groups that matter to your business users.
- We confirm which Metabase edition covers your SSO, row-level permission and identity provider needs.
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we build
- We deploy Metabase with PostgreSQL as the application database in your own environment.
- We connect Metabase to your existing data sources and configure groups and permissions to match your access model.
- We rebuild priority questions and dashboards and test them with a sample of business users before rollout.
How we hand over
- We document the deployment, connections, permission mappings and the upgrade and backup procedure for your team.
- We provide a written record of which QuickSight assets were recreated, retired or left for later.
- Handover covers the runbook for application database backups and the approach to upgrading between Metabase releases.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Metabase version upgrades, backup checks and access reviews on a schedule you agree.
- Confirm with us in the quote which support tasks are included and which remain with your own platform team.
