Metabase is both an open-source business intelligence application and a commercial product with managed hosting, support, security, and embedding features. That combination makes it relevant to internal data teams and product teams building on a customer-facing analytics product, but the two use cases do not have the same delivery contract.
The useful question is not simply whether Metabase is free. It is whether its query experience, permission model, embedding path, and operating model fit the job you need to ship.
Metabase's Draw Is the Short Path From Connection to Chart, Not Self-Explanatory Data
Metabase offers two complementary ways to query data:
Visual query building: People can select data, join supported tables, filter, summarize, and visualize results without starting from SQL. Whether this becomes reliable self-service analytics still depends on understandable models, governed metrics, permissions, and user education.
Native queries: Analysts can write SQL, use variables and field filters, save results as Questions or models, and reuse them in dashboards.
This is not unique to Metabase, and tools such as Looker make different trade-offs around modelling and governance. Metabase's attraction is the relatively direct path from a database connection to visual exploration, not a guarantee that every dataset becomes self-explanatory.
Every Metabase Feature Lowers a Barrier Without Removing the Modelling Work Behind It
The No-Code Query Builder Lowers the First Question, Not the Field Definitions
The visual query builder is where Metabase shines for non-technical users. You select a data source, choose which fields to display, add filters, and group your results. Click "Visualize" and you have a chart.
The interface lowers the barrier to a first question. It does not remove the need to define trustworthy fields, measures, join paths, and access rules.
Saved SQL Questions Reuse Logic, Which Means They Also Reuse a Wrong Metric
For teams that need more control, Metabase includes a SQL editor where you can write custom queries, save them as reusable "Questions," and build dashboards from those saved queries.
Saved Questions and models can become inputs to later analysis, which helps teams reuse logic. Teams should still assign ownership and test important definitions so reuse does not amplify an incorrect metric.
Metabase Dashboards Ship Through Subscriptions or a Public Link, and Public Means Public
Metabase dashboards use a simple drag-and-drop interface. Create individual visualizations (called "Questions" in Metabase), then arrange them into cohesive dashboards.
You can add filters that apply across cards, organize content in collections, configure data and application permissions, and distribute dashboards through subscriptions or sharing. A public link is intentionally public and should not be used for private customer data.
Modular Versus Full-App Embedding Is a Component Choice, and Security Cuts Across It
Metabase's current documentation separates modular embedding from full-app embedding. Modular embedding places individual questions, dashboards, collections, or other components in a product; teams can use the React SDK or Metabase's script-based setup. Full-app embedding places the broader Metabase interface in an iframe and can be styled to match a brand.
The security choice cuts across that component choice:
- Public links are for information that can be seen by anyone who obtains the URL.
- Guest embedding can sign and scope a view, including locked parameters, but it provides less user-specific interaction than an authenticated session.
- Authenticated embedding carries user identity and permissions through SSO. It supports richer modular or full-app workflows and is a paid capability.
The Metabase embedding overview documents the current options and plan requirements. For a serious embedded analytics platform evaluation, prototype the precise path you intend to ship: authentication, tenant mapping, drill-through, exports, theming, accessibility, query latency, and failure states.
Metabase Cloud Versus Self-Hosted Is a Hosting Decision, Separate From the Embedding One
Embedding and hosting are separate decisions. Metabase supports a managed Cloud service and self-hosted deployment.
Self-Hosted Metabase Gives You the Deployment, Not an Automatic Data-Residency Answer
Metabase can run as a Java application or container on infrastructure your team controls. This lets a team control the deployment, network, application database, upgrade timing, and, where the licence permits, its own fork. It does not by itself prove that every connected service, support workflow, or integration meets a data-residency requirement.
The operating work includes:
- Infrastructure setup and ongoing maintenance
- Metabase and dependency upgrades
- Application-database backups and recovery tests
- Availability, scaling, monitoring, and alerting
- TLS, secrets, database credentials, and incident response
Metabase recommends a production application database rather than its default local development database. The application database contains Questions, dashboards, collections, users, and other configuration, so backing it up is part of the product's recovery plan. The burden is real, but its size depends on availability targets and the operating platform rather than a universal head-count rule. Your security and compliance review should cover the complete path, including the source database and identity provider.
Metabase Cloud Removes the Operating Work, Not the Architecture Review
Metabase Cloud manages the service infrastructure, application database, backups, monitoring, TLS, and most upgrades. According to the Cloud versus self-hosting documentation, teams using the modular embedding SDK still coordinate SDK version upgrades rather than assuming every part updates automatically.
Managed hosting reduces operating work; it does not eliminate architecture review. Confirm the available region, network path to data sources, encryption, subprocessors, incident commitments, and contract terms against your requirements. Self-hosting may be necessary for an air-gapped or customized deployment, but it is not the only possible answer to every compliance requirement.
A Zero Licence Fee Makes Metabase Free to Download, Not Free to Run
The Open Source edition has no licence fee. Total cost still has at least four variable parts:
- Software plan: Open Source, Starter, Pro, or Enterprise features and user charges.
- Hosting: Metabase Cloud or the infrastructure, storage, and network services behind a self-hosted deployment.
- Operations: upgrades, backups, monitoring, on-call response, performance tuning, and recovery testing.
- Product integration: authentication, tenant mapping, design work, accessibility, test coverage, and support for embedded users.
Metabase publishes current plan inclusions and charges on its pricing page. Do not freeze a purchase decision to numbers copied into a guide: price the expected users and optional usage, then add the internal operating and integration work. A zero licence fee can be economical, but it is not evidence that total cost is zero.
Permissions also need precise treatment. Metabase includes collection, data, and application permissions, while row and column security is a Pro or Enterprise feature. It can use user attributes to filter rows or restrict columns; it is not something every customer must build from scratch. Source-database roles and grants should remain a defence-in-depth boundary.
Metabase Fits When the Hard Path Survives a Prototype, and Team Size Alone Does Not Decide
Metabase is worth a prototype when its visual query builder and standard dashboard components cover the core questions, the supported data sources match your architecture, and its permission and embedding model can express your audience boundaries.
The prototype should include the difficult path, not just a sample dashboard:
- A representative slow query and expected concurrency
- The actual tenant-isolation rule and a cross-tenant negative test
- The required embed interaction, including filters, drill-through, exports, and mobile layout
- Brand, accessibility, localization, and content-management requirements
- Upgrade, backup, incident, and support ownership
Metabase may be a good fit for internal business intelligence, a managed deployment, a self-hosted environment, or a customer-facing product. It may be a poor fit when required visualizations, product interactions, governance, or operating commitments fall outside what the tested plan can support. Team size alone does not decide that.
For teams evaluating embedded analytics alternatives, compare the same product contract across tools: identity, tenant isolation, authoring, component control, performance, operations, and price. A purpose-built embedded analytics platform can transfer more of that work to a vendor; a self-hosted tool can give your team more deployment control. If the Metabase contract fails the prototype, continue with the Metabase alternatives comparison rather than treating either open source or commercial software as the default answer.
Where to go next
- BI tools comparison guide: which platforms survive being embedded, judged on the embedding rather than the connector list.
- Looker vs Metabase: looker and Metabase both support embedded analytics.
- BI Tools & Comparisons articles: every article in this cluster.
Ready to launch customer-facing analytics?
Stop losing customers to competitors with better analytics. Sumboard's customer-facing analytics platform lets you launch self-service dashboards in days, not months.
