Which open-source BI tool can replace Looker embedded analytics?
Metabase, Apache Superset and Lightdash each offer an embedding path, but their licensing and authentication conditions differ. Metabase provides guest embedding on every plan, including the free Open Source edition, and reserves SSO embedding for its Pro and Enterprise plans. Superset's embedded SDK uses guest tokens and sits under the Apache-2.0 license with no paid edition. Lightdash embedding requires a paid plan: Cloud Pro for the hosted service, or an Enterprise license key set through LIGHTDASH_LICENSE_KEY for self-hosted deployments. Confirm each vendor's current embedding terms in writing before you commit, because plan features change.
Whichever tool you choose, your application owns authentication and tenant or row-level filtering. With guest embedding, your server signs a token that defines what the viewer can see, so the customer filter must be fixed in that signed token or enforced in the dataset itself, where the browser cannot change it. Test that a viewer from one customer cannot alter the filter parameters, that rows are restricted in the warehouse or dbt layer, and that cached results, dashboard thumbnails and scheduled reports do not expose one tenant's data to another. In Superset, thumbnails, alerts and async queries depend on the caching layer and Celery workers, so include those paths in your tests.
Before a pilot, ask your team to list every embedded Looker dashboard, the filters it applies per customer and the user attributes it relies on. Map each one to a signed guest token, an SSO group or a Lightdash embed setting, then note which features the customers actually need, such as per-viewer SSO or custom roles, since those features drive the plan choice. Plan the hosting too: Metabase recommends PostgreSQL for its application database in production, and Lightdash's Enterprise on-premises setup requires PostgreSQL with the pgvector extension. DeployOpen can plan, implement and test the embedding and tenant isolation under a fixed scope agreed in writing before work starts.
How Looker embedding capabilities map to open-source options
This table maps Looker's signed embedding, SSO or user-based embedding and row-level filtering to the embedding options in Metabase, Apache Superset and Lightdash. Read each row alongside the plan or license it names, because embedding features often sit behind paid tiers or an enterprise key. Items marked to confirm should be checked in each product's current documentation before you commit to an architecture.
| Looker capability | Metabase | Apache Superset | Lightdash |
|---|---|---|---|
| Signed embedding for external viewers | Guest embedding on all plans, with your server signing the embed token | Guest token issued by your backend and used through the embedded SDK | Embedding is a paid feature; confirm the guest or signed access model in current docs |
| SSO or user-based embedding | Requires Pro or Enterprise plan for SSO embedding | Viewers authenticate through OAuth2, LDAP or database accounts managed by Flask-AppBuilder | SSO with SAML and SCIM sits on Enterprise; confirm how embed users map to roles |
| Row-level filtering per viewer | Row and column permissions require Pro or Enterprise; confirm guest filter support | Row-level security is available; confirm how it applies to guest tokens | Custom roles sit on Enterprise; confirm row filtering for embedded users |
| Paid plan or license needed | Open Source covers guest embedding; Pro adds SSO and row-level permissions | No paid edition; the Apache-2.0 project includes its embedding features | Cloud Pro includes embedding; self-hosted embedding needs LIGHTDASH_LICENSE_KEY |
| Work in your host application | Your backend signs tokens and passes viewer attributes to Metabase | Your backend requests guest tokens and scopes them to dashboard IDs | Your backend handles embed sessions; confirm SDK and token details in docs |
| Metadata database and hosting | PostgreSQL recommended for production; MySQL and MariaDB also supported | PostgreSQL 10 to 17 or MySQL 5.7 and 8.x for metadata | PostgreSQL with pgvector required for Enterprise license features |
When Metabase, Superset or Lightdash fits embedding
Each option embeds analytics differently, and the licensing boundary decides which embedding model you can use without a paid license. The cards below set out what each tool offers, where the paid line sits, and what your application team must build around the dashboards.
Metabase embedding
Metabase offers guest embedding on all plans, so your application can show signed dashboards to external users without a Metabase login. SSO embedding, which lets your existing users pass through with their own identity, requires the Pro or Enterprise plan. The open-source core is AGPL-3.0, while code in the enterprise directory falls under the Metabase Commercial License, so confirm which edition and features your build uses. Your app must sign each embed token and handle the session and permission mapping.
Apache Superset embedded SDK
Superset is Apache-2.0 with no paid edition, and its embedded SDK uses guest tokens so your back end can grant limited, read-only access to a dashboard. Because there is no commercial tier to buy, the licensing question is simpler, but you carry the work of issuing tokens, configuring the allowed domains and keeping the Flask-AppBuilder authentication in line with your identity provider. Confirm which guest token roles and row-level rules your version supports before you design access.
Lightdash embedding with a license key
Lightdash is MIT licensed outside its ee directory, but embedding is one of the features unlocked by an Enterprise license key set through LIGHTDASH_LICENSE_KEY. The self-hosted path also needs PostgreSQL with the pgvector extension. Metrics stay in dbt YAML in your Git repository, which keeps the embedded numbers consistent with the rest of your warehouse reporting. Ask the vendor to confirm which embedding features each paid plan includes before you commit to the design.
Licensing boundary for each tool
The embedding decision often depends on license scope more than on features. Metabase and Lightdash both split code into open and commercial parts, while Superset ships everything under one permissive license. Have legal review whether your product is distributed to customers or used internally, because AGPL obligations and commercial directory terms can differ in each case. Treat this as a question for your counsel and the vendors' license texts, not a settled conclusion.
App-side work for every option
Whichever tool you choose, your application team owns the token signing, the identity mapping between your users and BI roles, and the handling of expired sessions. Plan for a back-end endpoint that issues short-lived tokens and tests that a user cannot see another tenant's data. Upgrades also change the embed code path, so schedule regression tests against embedded dashboards on every BI release.
What the host app must build for each embedding path
With Metabase, your application creates the embed and holds the signing secret, so it decides which dashboard or question a visitor can open and which parameters are locked. Guest embedding is available on every plan, including the free Open Source edition, while SSO embedding requires Pro or Enterprise. Confirm current plan terms on the Metabase pricing page before you design around either option.
- Signing endpoint: build a server route that checks the user's own session, creates a signed token for the specific dashboard or question, and sets the expiry and locked parameters on the server.
- Secret handling: keep the embedding secret in your back end's secret store, out of front-end code and out of public repositories, and plan its rotation with the deployment team.
- Tenant and row rules: place the tenant identifier in the signed payload so each embed returns only that customer's rows. Row and column permissions for signed-in users need Pro or Enterprise.
- Front-end rendering: load the signed URL in an iframe or through the Metabase embedding SDK, and add the host domain to your content security policy so the frame is allowed to load.
- Identity mapping for SSO embedding: on Pro or Enterprise, map identity provider users and groups to Metabase groups so the host application and the BI tool agree on who the visitor is.
Test that a token issued for one tenant cannot display another tenant's rows, and have your security team review the signing code path before go-live.
Superset's embedded SDK works with guest tokens. Your back end authenticates the end user, asks Superset for a guest token scoped to one dashboard and the current tenant's filter, and passes that token to the browser, which renders the dashboard through the SDK. Superset has no paid edition, so the cost of this path is the engineering, hosting and testing your team carries for the integration.
- Dedicated service account: create a Superset account that can read only the dashboards used in embeds, and keep its credentials on the server.
- Guest token endpoint: your back end requests the guest token with the dashboard identifier and the tenant's row filter, and never returns the service credentials to the browser.
- Row-level security: define row filters for the tenant column in Superset, then confirm in staging that a token for one tenant returns no rows belonging to another.
- Secret key and sign-in: Superset requires a user-specified SECRET_KEY to start, so set it from your secret store. Internal users sign in through Superset's OAuth2, LDAP or database authentication, while embedded viewers rely on the guest token your app issued.
- Front-end rendering and origins: mount the embedded SDK with the dashboard identifier and a token fetch function that calls your endpoint, then allow the host domain in Superset's embedding settings and your content security policy.
Confirm the exact embedding and guest token options in the Superset version you plan to run, and review its upgrade notes before each upgrade, since embedding settings can change between releases.
Lightdash embedding is a paid feature. It is included with Cloud Pro on Lightdash Cloud, and on self-hosted deployments it is unlocked by a license key set through the LIGHTDASH_LICENSE_KEY environment variable, along with a PostgreSQL database that has the pgvector extension. Your application still signs or issues the embed session and enforces which project, space and rows each viewer can reach, while metric definitions come from the dbt project in your Git repository.
- License and database prerequisites: set LIGHTDASH_LICENSE_KEY on the Lightdash services and confirm that the PostgreSQL metadata database has pgvector before you build the embed.
- Embed session endpoint: your back end issues the embed session for one dashboard or chart based on the signed-in user's tenant and role, and the browser receives only the short-lived result.
- Scope enforced in the host: decide which project, space and filters each tenant may see, enforce that in the token request, and never trust tenant or filter values sent from the browser.
- Roles and service accounts: custom roles and service accounts are part of the Enterprise license features, so map host users to the least-privileged Lightdash role that the embed needs.
- Front-end rendering: place the returned embed URL in an iframe, and allow the Lightdash origin in your content security policy.
Confirm with Lightdash which embedding options your plan and license key include, then test one tenant's embed against another tenant's data before go-live.
How signed and guest embedding flows through your application
The embedding flow starts in your host application, not in the BI tool. A signed-in user opens a page that contains a dashboard, and the host's server checks that the user may see that content. The server then issues a short-lived token or signed URL that identifies the dashboard and the filter values the server has chosen. The browser receives only that token and loads the dashboard in an iframe or, for Superset, through its embedded SDK. The BI server verifies the signature against a shared secret before rendering. Illustrative: an invoice page for tenant 42 receives a token whose filter is set by the server session, so the browser never supplies the tenant identifier itself.
Tenant isolation depends on where the filter is enforced. Filters must be set when the token is issued and must constrain the query the BI tool runs, not only the initial dashboard view. Confirm for each product whether a viewer can remove or change an applied filter, and whether the restriction carries into drill-through and exports. Metabase offers guest embedding on all plans, while SSO embedding requires Pro or Enterprise. Superset uses guest tokens through its embedded SDK, and Lightdash embedding requires a paid plan, with on-premises features unlocked by the LIGHTDASH_LICENSE_KEY variable. Protect the signing secret carefully: Superset requires a SECRET_KEY and supports rotation with PREVIOUS_SECRET_KEY. Test isolation by requesting each tenant's dashboard with another tenant's session and confirming that no rows leak.
Expiry needs a designed path. When a token expires, the embedded view stops rendering or prompts for re-authentication, depending on the product, and the host must issue a fresh token. Confirm how each vendor sets token lifetime, whether the iframe refreshes silently, what the end user sees, and whether closing the host session ends embedded access. Log every token issuance with tenant, dashboard and time so that access can be reviewed. Add an expiry scenario to your staging tests, because a refresh that fails quietly often shows up first as blank dashboards in production.
Moving embedded dashboards off Looker
This sequence moves each embedded dashboard and its tenant isolation from Looker to a self-hosted platform one customer at a time, so the host application keeps serving users throughout and Looker embed can be retired at contract end.
Inventory embedded content and endpoints
The host application team lists every place the product embeds Looker: the iframe or SDK call, the signed URL generator, the Looks and dashboards each embed loads, and the customer segments that see them. Record which embed user attributes and filters each request sends, since these define tenant boundaries. Done when every embed endpoint has an owner and a row in a shared inventory that the migration team signs off on.
Confirm the Looker embed contract terms
Procurement and the product owner check the current Looker embed agreement, including the edition in use, the renewal date and any notice period for ending the embed service. Looker Embed edition terms are covered on the sibling pages, so this step only confirms the dates that set the cutover deadline. Done when the end date is written in the migration plan and every stakeholder has the same date.
Recreate models against the warehouse
Data engineers rebuild each embedded view as a governed model on the same warehouse tables. For Metabase, this means models and metrics; for Superset, datasets and metric definitions; for Lightdash, metrics in dbt YAML. Keep the warehouse as the source of truth and document where each measure is defined. Done when the rebuilt results for each embedded dashboard match Looker output on a shared sample of queries.
Re-implement tenant filters in the host app
Because Looker user attributes no longer apply, the host application or the BI platform must enforce each customer's row restrictions. Metabase Pro or Enterprise offers row-level permissions, while the open source editions depend on filters the host app injects. Confirm which option the chosen tool supports before design begins. Done when a test account from one tenant cannot see another tenant's rows in any embedded view.
Build embed token issuance
Engineers replace the Looker signed URL generator with a token service in the host back end. Each platform has its own embedding model: Metabase guest and SSO embedding, the Superset embedded SDK with guest tokens, or Lightdash embedding on its paid plans. The service signs short-lived tokens only after the host app checks the user's session and tenant. Done when a penetration test or internal review confirms tokens expire and cannot be reused across tenants.
Run a parallel embed in staging
The team serves the same dashboards from Looker and the new platform in a staging copy of the product, using the same test accounts and data snapshot. Compare filter behavior, drill-downs, permissions and load times, and log each gap. The new platform also needs its own upgrade routine and backups before production. Done when the open issues list is closed or accepted by the product owner.
Cut over one customer at a time
Teams switch a small set of customers to the new embed, watch error rates and support tickets, and then move the rest in groups. A feature flag or per-tenant configuration lets the host app fall back to Looker for any customer that reports a problem. Done when every customer is on the new embed and the fallback path has been unused for an agreed period set by the product owner.
Decommission Looker embed after the contract ends
After the agreed end date, the team removes the Looker SDK, signing code and endpoints, revokes API credentials and confirms with the vendor that embed access has stopped. Retain exported dashboards, LookML copies and audit records under the organization's retention policy. Done when no production traffic reaches Looker embed URLs and the decommission record is filed with the compliance team.
What drives the cost of self-hosted embedding
Self-hosted embedding costs come from four places: the engineering inside your host application, the BI service you run, the warehouse queries that embedded viewers trigger, and the licensing tier that unlocks the features you need. Some of these are one-time build work and others recur every month and every upgrade cycle.
Host app engineering for tokens and tenancy
Signed or guest embedding means your own application issues the token, decides which dashboard a user may see and passes the tenant filter that limits their rows. This is custom code in your stack, written once and then maintained as your authentication and roles change. Ask any quote to name who builds the token endpoint, who tests tenant isolation and who owns the code after handover. Plan for this work to be the largest one-time item for most embedded deployments.
BI hosting and application database
Each option runs as a service you host: Metabase as a JAR or container, Superset as a Python application with its own metadata database, and Lightdash with PostgreSQL and object storage. Recurring costs are the compute, backups and monitoring for these services, plus high availability if embedded dashboards sit on customer-facing pages. Confirm the metadata database engine you will run in production, since the default embedded databases are not intended for production use.
Warehouse load from embedded viewers
Every embedded viewer triggers queries against your warehouse, and external users can open dashboards far more often than internal analysts. The cost is driven by how many queries run, how large they scan and whether results are cached. Ask the vendor or integrator how caching, refresh schedules and query limits are configured, and model expected concurrent viewers before you agree a warehouse budget.
Upgrade and patch routine
Embedded dashboards are customer-facing, so an upgrade that breaks an embed is visible to users. Metabase runs database migrations automatically and recommends backing up the application database first. Superset requires a backup, superset db upgrade, superset init and staging tests, with UPDATING.md checked for breaking changes. Lightdash ships new versions frequently. This routine recurs, so ask for its frequency, staging environment and who is on call for it.
Paid tiers for embedding features
Embedding is not free on every option. Metabase guest embedding is available on all plans, but SSO embedding requires Pro or Enterprise. Lightdash embedding is on its paid plans, and self-hosted Enterprise features need a LIGHTDASH_LICENSE_KEY. Superset's embedded SDK with guest tokens has no paid edition. Before you compare totals, confirm which embedding mode you need and which license it requires, and ask each vendor to put that in writing.
Questions teams ask before replacing Looker embedding
How much effort does replacing Looker embedding take?
Effort depends mainly on how many embedded dashboards and filters you have, how much of the host application's authentication you can reuse, and how far the data model has to change. Each embedded view needs a host-side endpoint or SDK call that issues a signed or guest token, a styled container in your application, and a test of what each customer or user can see. Teams that already have clean warehouse tables and a stable user identity model usually have less to rebuild than teams whose Looker models hold most of the business logic. Ask any implementer for a written breakdown by dashboard count, filter complexity and identity work before accepting a figure.
Can our team migrate embedded dashboards without outside help?
A team with application engineers, a data engineer who understands the warehouse, and someone who owns the identity provider can often do the work in-house, and the open-source tools are documented for that. The harder parts are usually the security design of tokens and tenant isolation, the upgrade routine for a self-hosted analytics stack, and the validation that numbers match the old Looker dashboards. If those skills are thin, an outside team can take a fixed scope with written deliverables, or you can retain ongoing support after the first release. DeployOpen implements, hardens and documents self-hosted platforms in your own infrastructure, and it works from a written scope agreed before work starts.
How long does an embedded dashboard migration take?
The timeline depends on scope, not on a single standard duration. The main drivers are the number of embedded dashboards, whether metric definitions move from LookML into dbt or warehouse views, how many tenants or permission rules must be reproduced, and how many parallel runs you need before cutover. Lightdash embedding is documented on its paid plans and Metabase guest embedding is available on all plans, so licensing can also change the sequence of work. Ask for a plan with milestones for a pilot dashboard, a full set of embeds, and a parallel-run period against the existing Looker output.
Does guest embedding in Metabase require a paid plan?
No. Guest embedding is available in Metabase on all plans, including the free Open Source edition, according to Metabase's embedding documentation. SSO embedding is the feature that needs a paid tier, specifically Pro or Enterprise. Guest embedding suits public or anonymous views and simple per-customer dashboards, while SSO embedding fits cases where each end user must be recognized with their own permissions. Confirm current plan entitlements on Metabase's pricing page before you commit, because plan contents change over time.
How are Apache Superset guest tokens secured?
Superset's embedded SDK relies on guest tokens issued by your backend, so the host application decides which dashboards and filters a viewer receives. The backend must authenticate the user before requesting a token, scope the token to specific dashboard resources and row-level filters, and keep the signing secret out of browser code. Superset itself requires a user-specified SECRET_KEY at startup, and it supports rotation with PREVIOUS_SECRET_KEY, so plan a key management process from the start. Have a security engineer review the token issuance path and test that one tenant cannot request another tenant's filter values.
What does Lightdash need to embed dashboards?
Lightdash embedding is part of its paid plans, so you need a Cloud Pro or Enterprise subscription, or an Enterprise license key for self-hosted deployments. For self-hosting, Enterprise Edition features need the license key set through the LIGHTDASH_LICENSE_KEY environment variable and a PostgreSQL database with the pgvector extension. The host application also needs a backend that issues embed access for each viewer, and a dbt project that defines the metrics the embedded charts use. Confirm the exact embed configuration steps with Lightdash's current documentation before you design the token flow.
What skills must our internal team provide during the migration?
Your team needs application engineers who can add a token endpoint and an embed container to the host app, a data engineer who can move metric logic from LookML into dbt YAML or warehouse views, and an identity owner who can map your sign-in system to embed permissions. Someone must also own the self-hosted stack after launch, including backups of the metadata database, upgrades, and monitoring of the caching and worker components if you run scheduled reports. Lightdash documents its self-hosted guide for DevOps engineers familiar with Docker and Kubernetes, so plan for that skill set. Write these responsibilities down before the engagement starts so that gaps are visible early.
How DeployOpen scopes and delivers embedded analytics
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For embedded analytics, that means agreeing in writing which host application, identity model and data sources the embedded dashboards will serve before any build work starts.
How we scope
- Confirm which embedding pattern fits: guest embedding, SSO embedding or a signed token flow in the host application
- Inventory the dashboards, datasets and end-user roles that the host application must expose to customers or staff
- Record the written scope, deliverables and timeline agreed with your team before work starts, as engagements are fixed-scope
How we build
- Deploy the chosen open-source BI platform in your cloud account, data center or air-gapped network with the agreed metadata database
- Integrate the embedding layer with your identity provider and enforce row-level access rules tied to the tenant or user
- Test embedded views for permission leakage, token handling and session expiry, and document the results for your security team
How we hand over
- Provide architecture notes, configuration records and runbooks covering the host app, BI platform and database connections
- Walk your engineers through upgrade steps, including application database backups and staged testing before each release
- Document which embedding features depend on a paid edition or license key, so your team can confirm them with each vendor
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover version upgrades for the embedding stack, security re-testing and changes to dashboards or permissions
- Ask any quote to itemize one-time build work separately from recurring support, so the recurring cost is visible
