Embedding Metabase dashboards in a SaaS product: the three modes and multi-tenant isolation

You built a SaaS product and your customer wants to see their own numbers inside it — not in another tool, behind another login. Metabase solves this with embedding, but "embed a dashboard" hides three very different modes and one question that decides everything: how to guarantee each customer sees strictly their own data.

Sending the customer to a separate tool costs context, login and adoption. Embedded analytics — dashboards inside your own interface, with your brand — becomes part of the product: the data shows up where the decision happens. The question is never whether, it is how — and the "how" in Metabase has three forms.

• Static embedding (signed) — an iframe with a server-signed JWT. The parameters (for example, the customer identifier) travel locked inside the token; the user neither interacts with nor alters them. Ideal for a fixed panel per customer. Available in open source.
• Interactive embedding — full Metabase embedded, with SSO login (JWT), where the customer explores and builds their own questions. Requires Pro/Enterprise and pairs with data sandboxing.
• Embedded analytics SDK (React) — Metabase components inside your application, with fine control over layout and theme. An Enterprise feature.

In a multi-tenant product, the worst possible mistake is one customer seeing another customer data. Safe isolation depends on the mode:

• Static embedding — the tenant travels as a locked parameter inside the JWT signed in your backend. Because the token is signed with a server secret, the customer cannot forge a different identifier. This is the isolation path on open source.
• Interactive embedding + data sandboxing — row-level filtering is applied automatically based on the JWT user, even if they explore freely. It is the strongest isolation for open exploration — and it is Enterprise.
• OSS without sandboxing — when you need exploration on open source, the route is to separate data per connection/schema per tenant (the same architecture from our article on governance on open-source Metabase).

• Pass the tenant_id in an editable URL parameter — the customer swaps the number and sees the neighbor.
• Embed without a signature (public embed) thinking "no one will guess the URL".
• Trust the front-end to filter — the filter must live in the signed token or in the database, never in JavaScript.

Rule of thumb: if the customer only needs to view a panel per tenant, signed static embedding handles it — and runs on open source. If they need to explore and build questions with row-level isolation, it is interactive embedding + data sandboxing (Enterprise). If exploration is needed but the budget is OSS, separate the data per tenant in the architecture. The mistake is choosing by the shine of the demo, not by the real isolation requirement.