Metabase embedding lets a US SaaS team place Metabase dashboards inside its product in a few days, using signed embeds for fixed views or interactive embedding for exploration. It gets harder once many tenants need their own permissions, styling and dashboards. Native dashboards that customers build inside the product avoid the separate-tool seam, but they ask more of your platform.

Key takeaways

• Fast start, slower finish: Metabase embedding is a quick way to ship analytics, but per-tenant rules, theming and custom views are where your team's time goes.
• Tenant safety is your job: Your server must sign the tenant id into every embed; one missing filter can show a customer another customer's data.
• Customization is a queue: In an embedded BI tool, every customer-specific dashboard still needs a person with BI access to build it.
• Native changes the owner: With native dashboards, customers create views themselves, in plain English, under the permissions they already have.
• Use both when it fits: Embed Metabase for stable, shared analytics; go native for customer-specific views.

Metabase embedding vs native dashboards at a glance

Question	Metabase embedding	Native dashboards customers build
Who builds the dashboard?	Your team or an analyst with Metabase access	The end customer, in plain English inside your product
How is tenant data isolated?	Your server signs the tenant id into the embed token; you maintain that rule	Extensions inherit your existing authentication, permissions and access controls
Look and feel	A separate tool inside a frame; theming depends on edition	White-labeled, matches your design system
Per-customer variation	Each variant is built and maintained in Metabase	Each customer creates their own capability
Governance	Handled in Metabase plus your app	Central control plane for publishing, permissions and approvals
Best fit	Shared, stable analytics	Customer-specific dashboards, reports and workflows

How does Metabase embedding work?

Metabase embedding places a Metabase question or dashboard inside your application, usually through an iframe or a JavaScript embed. Your app decides who sees what by signing a token on the server. Metabase then renders the result. Fuller interactive modes let users click through, filter and explore data themselves.

Metabase's own documentation describes two broad uses: running it as a BI tool for your own team, or embedding it in your app so customers can explore their own data. The public docs also say Metabase connects to more than 20 data sources and queries your database live, rather than ingesting or refreshing a copy of it.

Public docs also describe an SDK that works with React, plus a modular embedding option that works with other frameworks. Which of these you can use depends on your Metabase edition, so confirm against the current docs before you plan a build.

Signed embeds vs interactive embedding

These two are often lumped together, but they are different products for your customer. Here is the practical split.

Signed (guest) embeds show a fixed question or dashboard. Your server creates a signed token that carries parameters, such as the tenant id, and the embed only displays what that token allows. Metabase's docs say this approach works on every edition, including the free open-source one, using a locked parameter that only your server can set.

Interactive embedding puts more of Metabase in front of the user, so they can browse, drill down and build their own questions. It suits customers who want to explore. It also raises the stakes, because more of the tool is exposed. Some of these capabilities sit in paid plans, so check the docs for what your edition includes.

The tenant id flow in plain steps

1. The user signs in to your product, and your app knows their tenant.
2. Your server reads that tenant id from its own session, never from the browser.
3. It signs the id into the embed token as a locked parameter.
4. Metabase filters the data using that parameter and returns the view.
5. The browser shows only the result.

Pass mark: the tenant id must come from your server-side session. If any step reads it from a URL, a cookie the user can edit or a client-side field, treat it as a failed check and fix it before launch.

Where does Metabase embedding get hard in multi-tenant SaaS?

Metabase embedding gets hard where multi-tenancy meets variety: enforcing tenant filters on every embed, matching your brand, and supporting dashboards that differ per customer. The first is a security risk, the second a design limit, and the third a growing workload for whoever owns the Metabase instance.

Permissions: the filter you cannot forget

With signed embeds, your app keeps its own tenant rule and the embed carries only the result. That is a clean model. The catch is that the rule lives in your code and in each question's configuration, so a question built without the locked parameter can expose rows across tenants.

Metabase's own multi-tenant guidance puts it bluntly: one missing filter can show one customer another customer's data. In practice, treat every new dashboard as a security change. Review it the way you review a new API endpoint.

Permissions also live in two places. Your product has roles, such as admin, manager and viewer. Metabase has its own collections and data permissions. Keeping them in sync means a role change in your product needs a matching change on the Metabase side, or a deliberate decision to ignore role differences.

Styling: close, but still a separate tool

An embed is a frame around a different application. You can usually bring colors and fonts closer to your brand, and how far you can go depends on your edition and embedding mode. Spacing, chart behavior, empty states and error messages still come from Metabase, not your design system.

Customers rarely complain about a font. They notice when filters behave differently from the rest of your product, or when a dashboard loads with a different feel. That seam matters most in products that sell on polish.

Per-customer customization: where the queue forms

Signed embeds are strongest when every tenant sees the same dashboard with different data. They are weakest when each tenant wants a different dashboard. Every new variant has to be built, tested and maintained by someone with Metabase access.

Consider a hypothetical product with 120 customers. Suppose 15 of them ask for a tailored view each quarter. That is 60 variants a year to build, secure and keep working, each one a small project for an analyst or engineer. Your own numbers will differ, but the shape holds: demand per customer grows faster than a shared dashboard set can absorb.

Operations: keep the tool patched

If you self-host, Metabase becomes part of your attack surface. The US National Vulnerability Database lists CVE-2026-59826, which affects Metabase from 1.55.0 until fixed releases (1.58.15.1, 1.59.12, 1.60.6.3 and 1.61.2). An earlier entry, CVE-2022-24855, covered a cross-site scripting issue in an internal endpoint.

None of this is a reason to avoid Metabase; any software needs patching. It is a reason to put an owner and an upgrade routine in your plan. The US Department of Veterans Affairs lists Metabase in its Technical Reference Model as an open-source technology, alongside adoption risks that its teams must handle.

What are native embedded dashboards customers build inside the product?

Native embedded dashboards are views that customers create inside your product itself, usually by describing what they want in plain English. They run on your live data, inherit your authentication and permissions, and look like part of your application, rather than a separate tool in a frame.

This is the model Vezel builds. Vezel is an embedded AI extension platform: it connects to your APIs and data models with a zero-footprint setup, then lets customers generate dashboards, reports, forms, workflows and AI assistants from plain English. Extensions are white-labeled and inherit your existing authentication, permissions and access controls.

Governance moves to a central control plane that manages publishing, permissions, approvals and the extension lifecycle. Most SaaS platforms can integrate Vezel in a few days, according to our own onboarding experience.

What the Flexibiz demo shows

Flexibiz is an ERP for the packaging industry, and it appears in our demos. Its dashboards are AI-powered and live directly inside the ERP. Users create, customize and explore dashboards inside Flexibiz instead of exporting reports to Excel or building charts by hand.

That is the real difference in daily use. The person who knows what a good view looks like is the one building it, in the product they already log in to. For a deeper look at the build process, see our guide on building custom dashboards inside your SaaS.

What native does not give you for free

Native is not simply better. You still need clean APIs and sensible data models, because generated dashboards are only as good as the endpoints behind them. You also need rules about who may publish a dashboard to others.

And there is an open question we cannot settle for you: how much self-serve power your customers actually want. Some will happily build views in plain English; others want a finished dashboard on day one. Your usage data will tell you that faster than any article.

Metabase embedding vs native dashboards: side-by-side comparison

Factor	Signed Metabase embed	Interactive Metabase embed	Native in-product dashboards
What the user can do	View a fixed dashboard or question	Explore, filter and drill into data	Describe and create their own views
Tenant isolation	Locked parameter signed by your server	Same principle, with more of the tool exposed	Inherited from your authentication and permissions
Styling	Frame around a separate tool	Frame around a separate tool	White-labeled to your design system
Per-customer variants	Built by your team in Metabase	Customers explore, but saved views live in Metabase	Customer-created, governed centrally
Data approach	Queries your database live	Queries your database live	Connects to your APIs and data models
Main work for your team	Token signing, filters, theming, upgrades	Same, plus managing a wider surface	Clean APIs, publishing rules, governance
Best for	Same dashboard for every tenant	Data-savvy customers who explore	Each customer needs different views

For a wider view of the market, our overview of embedded analytics approaches for SaaS covers iframe BI, SDK dashboards and customer-built options together.

When does each approach fit a SaaS roadmap?

Choose Metabase embedding when every customer needs the same few dashboards and your team has analyst capacity. Choose native dashboards when customers keep asking for views that differ by account. If both are true, embed Metabase for the shared core and add native for customer-specific needs.

Pick Metabase embedding if

• You need analytics in the product this quarter and the dashboard set is small and stable.
• Your tenant model is simple: one tenant id, one filter, applied the same way everywhere.
• Someone on your team will own Metabase, including upgrades and dashboard review.
• Your customers accept a slightly different look inside a frame.

Pick native dashboards if

• Different customers define the same metric differently, and you cannot standardize them.
• Your product wins on a consistent look, and a visible seam would cost you.
• Permissions are detailed (row-level or role-based) and you do not want to mirror them in a second system.
• You want customers, not your analysts, to create the long tail of views.

The mixed approach

Many teams will land here. Keep a handful of shared, high-traffic dashboards in an embedded BI tool, where they are cheap to maintain. Let customers build the rest natively. Our guide to choosing an embedded extensibility platform lists the questions to ask any vendor before you commit.

If we had to choose for a B2B product with enterprise accounts, we would start native for anything customer-specific, because that is where the queue forms. For a single shared usage report, Metabase embedding is usually the quicker route.

A pre-decision checklist for product and engineering leaders

Run these five checks before committing to either path. Each has a pass mark, and a fail tells you what to do next.

1. Tenant test: Log in as tenant A and try to load tenant B's data by editing every parameter you can reach. Pass: nothing returns. Fail: stop and fix server-side signing first.
2. Variant count: List the dashboards customers asked for in the last two quarters. Pass: most are the same dashboard with different data. Fail: if many are unique, plan for native.
3. Brand check: Show the embed to a designer. Pass: they cannot tell it apart at a glance. Fail: expect complaints, or move to a white-labeled native approach.
4. Ownership: Name the person who patches and reviews. Pass: a named owner and a routine. Fail: do not self-host yet.
5. Permission map: Write down every role in your product and what it may see. Pass: the model fits in one filter. Fail: you need inherited permissions.

FAQ

Is Metabase embedding free?

Metabase's public docs say guest embeds work on every edition, including the open-source one. Some interactive and styling features belong to paid plans. We do not quote pricing here, so check the current Metabase docs for what your edition includes before you design around a feature.

Can Metabase handle multi-tenant data safely?

Yes, when your server signs the tenant id into each embed as a locked parameter and every question uses it. The risk is human: one question built without the filter can leak data across tenants. Review each new dashboard like a code change, and test with a second tenant.

Can native dashboards and Metabase run side by side?

Yes. Many teams keep a few shared dashboards in an embedded BI tool and let customers build account-specific views natively. The split works best when you define in advance which dashboards your team owns and which belong to customers.

Next step: see native dashboards on your own product

If your Metabase embedding plan is stalling on tenant rules, theming or the long tail of customer-specific views, test the native path before you commit. Share a demo account and we will build a working proof inside your SaaS, using your APIs and permissions. Book a Demo to see it, or review how it works first. You can also email hello@vezel.ai; we reply within 1-2 business days.

Recommended Resources

Book a Demo

• See How It Works
• Talk to an Expert