How OpenMetadata Superset integration gives dashboards owners and lineage
This section covers how a data team running Superset, Metabase or both gets its dashboards and charts cataloged in OpenMetadata and traces lineage from warehouse tables to the dashboards that read them. Many teams can name their warehouse tables and their dashboards, but cannot say quickly which dashboards break when a table changes. The exact method depends on the connector in the OpenMetadata release you run. OpenMetadata lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms, and it supports dashboard and table lineage. Confirm in the connector documentation for your version whether Superset and Metabase are covered, and whether that coverage comes through metadata ingestion, OpenLineage events or the REST API.
Before you configure anything, decide what the catalog should say about each dashboard. Check what the connector extracts for each tool: dashboard and chart names, descriptions, owners, and the tables or datasets each chart queries. Superset builds charts on datasets, while Metabase organizes saved questions and dashboards into collections, so the same business owner may appear in different places in each tool. Agree on one owner field for each dashboard and a rule for dashboards that have no named owner. Those decisions determine whether the catalog can answer the question of who to contact when a dashboard looks wrong, and they are much cheaper to settle before the first ingestion run than after.
Lineage needs its own decision. If the connector derives table-to-dashboard edges from the queries behind each chart, accuracy depends on how the connector parses those queries, including Metabase native SQL and Superset virtual datasets that reference other SQL. If the connector relies on OpenLineage events, confirm that the BI tool or its surrounding pipeline emits them and that OpenMetadata receives them. If the approach uses the REST API, your team writes and maintains the scripts that create the edges. Test each method against three dashboards whose source tables you already know, and record which edges are missing before you treat the lineage graph as the basis for impact analysis.
The ingestion account decides what the catalog can see. Superset needs a read-only service account whose roles cover the dashboards and datasets you want cataloged, and Metabase needs an account or API key with permission to read the collections in scope. Metabase limits SSO and row and column level permissions to its Pro and Enterprise plans, so confirm which permissions your plan provides before you rely on them to scope access. A dashboard the account cannot read will be missing from the catalog and from its lineage, and nothing in the graph will flag that gap. Ask the team that owns each BI tool to confirm the account's role in writing before ingestion starts.
Plan verification and ongoing runs before go-live. Run a test ingestion against a staging copy of each BI tool, compare dashboard and chart counts with what the tool shows, and check that owners match. Schedule re-ingestion so new dashboards appear, and confirm how the connector handles dashboards that are deleted or moved. Rerun the same test set after any OpenMetadata or BI tool upgrade, because connector behavior can change between releases. Superset's upgrade guidance asks teams to back up the metadata database and test in staging first, and Metabase's upgrade guidance asks for an application database backup first, so include both steps in the upgrade plan for the catalog.
What you need before connecting OpenMetadata to Superset and Metabase
The connection runs between three systems you operate: OpenMetadata as the catalog, Superset and Metabase as the BI tools, and the warehouse both read from. Each card covers a decision or prerequisite to settle before connectors are configured, because the catalog, the BI metadata stores and the service accounts all depend on them.
OpenMetadata deployment and runtime
OpenMetadata runs on Kubernetes (AWS EKS, Azure AKS, Google GKE or on-premises clusters) or on bare metal, and Docker is documented for local trials only. Bare metal needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The documented minimums are 2 vCPUs, 4 GB RAM and 20 GB storage for the server, and at least 2 vCPUs, 2 GB RAM and 30 GB storage each for the database and search services. Treat these as floors and ask your platform team to size for the dashboards and lineage you plan to catalog.
OpenMetadata 2.0.0 breaking changes
OpenMetadata 2.0.0 was released on August 24, 2026. Its breaking changes include moving embedding credentials into an llmConfiguration block, a new Databricks authentication format, rebuilding custom ingestion images for Python 3.12, and migrating Great Expectations to 1.3 before upgrading. If you already run a 1.x release, complete these changes in staging before you add the Superset and Metabase connectors, so an upgrade problem does not hold up the BI rollout.
Superset metadata database and secret key
Superset is tested with PostgreSQL and MySQL as its metadata database, and the configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x as supported versions. SQLite, the default in Quickstart and PyPI installs, is not recommended for production, and the Docker Compose PostgreSQL container is also not recommended for production. Superset requires a user-specified SECRET_KEY to start, so generate it and store it in your secrets manager before the first run, and confirm your rotation procedure using PREVIOUS_SECRET_KEY.
Superset caching layer and Celery workers
Superset's architecture documentation states that alerts and reports, async queries and dashboard thumbnails require the caching layer and worker components. Most installations use Redis for caching and Celery for the worker and beat processes. If you do not plan these features, the components stay optional, but confirm that decision with your Superset administrators before sizing the environment. Enabling alerts later means adding services to a running deployment, which is easier to plan at the start.
Metabase application database
Metabase keeps its operational data in an application database. It ships with an embedded H2 database for demos and recommends PostgreSQL for production, and MySQL 8.4.0 or MariaDB 10.6.0 and later are also supported with utf8mb4. If a trial instance used H2, Metabase documents a one-time load-from-h2 command to move the data, and that command must run with the same Metabase version that last updated the H2 file. Choose the production database before connecting OpenMetadata so the metadata and credentials are not tied to a demo store.
Read-only service accounts in each system
Create a read-only service account in Superset, in Metabase and in the warehouse, each limited to the schemas that ingestion and lineage need. Check each connector's documentation to confirm which metadata the account must read, since the BI accounts supply dashboard and chart details and the warehouse account supplies table and column metadata. Record who rotates these credentials, where they are stored and how access is removed when an owner leaves.
Which integration method fits Superset and Metabase
Start by choosing among the three methods OpenMetadata documents, because each one reads different facts about your BI tools. Connector-based metadata ingestion pulls dashboards, charts and their relationships from the BI tool's own API or, where the connector supports it, from its metadata database. OpenLineage event integration suits teams whose pipelines already emit run events, so lineage follows the jobs that produce and consume tables. The REST API and Python SDK cover what neither connector captures, such as custom ownership rules or dashboards in a tool without a connector. For Superset and Metabase, the connector route is usually the first choice. Before you commit, confirm in the connector documentation for your exact OpenMetadata release which Superset and Metabase versions and which fields are supported.
Table-to-dashboard lineage appears only when the warehouse table that OpenMetadata ingested and the table the BI tool reports refer to the same entity. In practice, that means matching service names, database names, schema names and table casing across both sides. Superset datasets often carry names that differ from physical table names, and Metabase questions reference tables through their own identifiers, so a naming gap can leave a dashboard attached to nothing or to a duplicate table. Ask your team to list how each warehouse database is named in the warehouse connector, in Superset and in Metabase, and to resolve differences before the first run. A small pilot against one warehouse schema exposes mismatches cheaply, long before they spread across the full dashboard estate.
Decide which system is the source of truth for dashboard ownership before the first ingestion. Superset and Metabase each store owners, descriptions, tags or collections, and OpenMetadata keeps its own owners, descriptions and tags. When ingestion runs again, it can update fields that people have edited in OpenMetadata, so an unplanned re-run can silently change ownership that a data steward already curated. Write down, field by field, whether the BI tool or OpenMetadata wins, and confirm how the connector you chose handles owners and descriptions set manually in OpenMetadata. Assign a named accountable team to dashboards that have no owner in the BI tool, because unowned dashboards generate the questions nobody can answer after go-live.
The Metabase edition you run also shapes the identity design, which affects how the ingestion account is created and how people sign in to both tools. According to Metabase's documentation, the open source and Starter plans support Google sign-in and LDAP, while JWT, OIDC, SAML, advanced LDAP group sync and SCIM provisioning require the Pro or Enterprise plans. If your organization needs an OIDC or SAML provider for Metabase, that requirement belongs in the edition decision made now. Create a dedicated read-only service account in each BI tool for ingestion, and confirm with the connector documentation which credential type it accepts. Superset supports OAuth2, LDAP and group-to-role mapping, so plan its ingestion account alongside those sign-in settings.
How to configure the Superset and Metabase connections in order
This sequence connects Apache Superset and Metabase to OpenMetadata so their dashboards and charts appear in the catalog, linked to the warehouse tables they read. Each step ends with a check, so you confirm the previous step worked before you start the next one.
Confirm the OpenMetadata release and connectors
Your team, with DeployOpen if you engage us, checks the OpenMetadata release you run against its release notes and the connector documentation for that exact version. Confirm that the Superset connector, the Metabase connector and your warehouse connector are all listed, and note any Python or Airflow requirements for ingestion. Record the edition of each BI tool you run, because Metabase features such as SSO and data permissions depend on the plan. Done when you have a written note of the release, the connectors, the BI editions, and the lineage method the docs describe for that release.
Create read-only service accounts in each tool
Create one dedicated account in Superset and one in Metabase for OpenMetadata to use, and do not reuse a personal login. In Superset, assign a role that can read dashboards, charts and datasets without edit or delete rights, and confirm the role names with your Superset administrator. In Metabase, confirm with your administrator which permissions the account needs on your edition, since data permission controls belong to the paid plans. Check: sign in as each account in a private browser window, open a dashboard it should catalog, and confirm that editing or deleting it is blocked.
Ingest the warehouse before the BI tools
Run the database service for your warehouse first so schemas, tables and columns exist in the catalog before dashboards arrive. Lineage from a dashboard points to table entities, so a BI run before this step produces dashboards with no upstream tables to link to. Use a read-only warehouse role and reference its credentials through the secrets mechanism your deployment uses. Check: the warehouse service appears in the catalog, and a sample table shows its expected schema and columns.
Configure and test each BI connector
Create a separate database service in OpenMetadata for Superset and for Metabase so their ownership and schedules stay independent. Enter each tool's base URL, and reference the service account password from the secrets mechanism your deployment uses, such as a Kubernetes secret store or a vault, instead of typing it into the form or a configuration file. Run the test connection action on each service. A passing test confirms network reach from the ingestion runner, TLS trust and that the account can authenticate. Check: every test reports success, and the saved configuration contains no plain-text credentials.
Run the first metadata ingestion
Start a manual ingestion for the Superset service, then for the Metabase service. Open each service and confirm that dashboards, charts and their datasets or questions appear with names that match the BI tool. Review the ingestion log for skipped entities and check any filter patterns you set. Check: a known dashboard opens in OpenMetadata with its charts listed, and the log shows no unexplained failures. If charts appear with no source table, return to the warehouse step and confirm the table names match.
Enable lineage using the documented method
Enable lineage with the method your chosen OpenMetadata release documents, either the OpenLineage event integration or the lineage setting in the BI connector, and check the docs before turning on both for the same flows. Lineage depends on the warehouse tables cataloged earlier, so the table names must match. Pick one table that feeds a known dashboard and open its lineage view. Check: the dashboard appears downstream of the table. If it does not, confirm the lineage setting is on, the release supports that method for your tool, and the table identifiers match.
Assign owners and domains to assets
Define your domains in OpenMetadata first, then assign an owner and a domain to each dashboard and to the source tables they use. Owners should be the team that maintains the dashboard, not the team that happens to run the ingestion. Agree on who approves ownership changes before the catalog goes live. Check: a sample of dashboards shows an owner and a domain, and a member of the owning team can find those assets from the domain view without help.
Schedule recurring ingestion for each service
Schedule the warehouse service first, then the Superset and Metabase services, so each run picks up the tables that the BI runs depend on. Choose the frequency with the owners of the dashboards and the warehouse, and confirm how your release handles schedules and retries in its documentation. Check: two consecutive scheduled runs complete for every service, and a dashboard you edit in its BI tool shows the change after the next run.
How dashboard, chart and ownership fields map between the systems
This table compares how Superset and Metabase objects line up with OpenMetadata dashboard, chart, table and ownership entities. Read the last column first for the entity each object should become, then check the confirm notes before you build the connector configuration. The main takeaway is that the warehouse table identifier and owner source must be decided before ingestion starts, because they determine whether lineage and ownership hold together.
| Concept | Apache Superset | Metabase | OpenMetadata entity and notes |
|---|---|---|---|
| Dashboards | Dashboard objects built from charts and filters | Dashboards holding saved questions (cards) | Dashboard entity. Confirm the field mapping in the connector docs for your release. |
| Charts | Chart (slice) bound to one dataset | Saved question (card) querying one source | Chart entity linked to its parent dashboard. Confirm how each BI tool reports the link. |
| Warehouse source | Dataset pointing at a database table or SQL | Question querying a table in a connected database | Table entity. Its fully qualified name must match the warehouse ingestion identifier. Confirm the format for your connector release. |
| Collections and folders | Dashboard organization by owner and roles | Collections holding dashboards and questions | No assumed equivalent. Confirm whether collections are imported or must be modeled with tags or domains. |
| Owners | Owners recorded on dashboards and charts | Creator of dashboards and questions | Owner entity (user or team). Confirm whether the connector imports BI owners or owners are set manually. |
| Groups and roles | Roles, which can be mapped from LDAP or OAuth groups | Groups; advanced group sync requires Pro or Enterprise | Teams or users. Group membership in the BI tool does not set catalog ownership automatically. |
| Domains | Not held in the BI tool; assigned in the catalog | Not held in the BI tool; assigned in the catalog | Domain assigned to dashboards, charts and tables in OpenMetadata. |
| Glossary terms | Not held in the BI tool; assigned in the catalog | Not held in the BI tool; assigned in the catalog | Glossary terms attached to tables and dashboards after review. Confirm term inheritance behavior. |
Security settings for OpenMetadata, Superset and Metabase connections
Each product in this stack has its own sign-in model, secret handling and access controls, and the catalog shows only what those controls allow. The cards below cover the settings a security reviewer will ask about, from identity and role mapping to database accounts and secret storage. Verify plan entitlements and version-specific settings against the vendor documentation before you decide.
OpenMetadata SSO options
OpenMetadata documents SSO with Auth0, Azure, Google, Okta, Amazon Cognito, OneLogin, Keycloak and custom OIDC providers, so your identity provider sets the sign-in model for the catalog. OpenMetadata does not run SSO and basic authentication together, so plan the cutover, administrator recovery access and the way ingestion service accounts will authenticate before go-live. Confirm the provider settings your version supports and test recovery in staging.
Superset SECRET_KEY before first start
Superset requires a user-specified SECRET_KEY to start, a requirement added in version 2.1.0. Set it before the first boot, store it in your secrets manager, and make sure no environment falls back to a default value. Rotation is supported with PREVIOUS_SECRET_KEY, so confirm in the configuration documentation exactly what the previous key covers, then rehearse the rotation in staging before you schedule it.
Superset group-to-role mapping
Superset is built on Flask-AppBuilder and supports OAuth2 providers such as Google and Azure, custom OAuth2 servers using the code flow, and LDAP. AUTH_ROLES_MAPPING maps LDAP or OAuth groups to Superset roles, so role assignments follow group membership in your directory. Define the roles your analysts and administrators need, and review the mapping after each change to your groups.
Metabase sign-in options by plan
Metabase Open Source and Starter support Google sign-in and LDAP. SSO, JWT, OIDC, SAML, advanced LDAP group sync and SCIM provisioning require Pro or Enterprise, which also include row and column permissions and auditing. Verify current plan entitlements on Metabase's pricing page before you choose a tier, because the sign-in and access controls you need may depend on it.
Read-only warehouse and BI credentials
Give Superset, Metabase and OpenMetadata's ingestion jobs their own database accounts with read-only grants limited to the schemas each one needs. Keep write and administrative privileges out of BI connections so that dashboard authors cannot change source tables. Review these accounts when new schemas are added, and decide whether Superset or Metabase permissions enforce your data policy or whether database-side grants must.
Secrets handling for connections and tokens
Connection passwords, API tokens and the Superset SECRET_KEY must live outside source code, shared documents and container images. Decide where each secret is stored, who can read it, and how it reaches each process at runtime. Check each product's documentation for how it accepts secrets from environment variables or a secrets store, and confirm that logs and the user interface do not display them.
How to verify lineage and metadata before the catalog is trusted
Treat the catalog as untrusted until a staging test plan has passed for both BI tools. Build a staging OpenMetadata deployment, a staging copy of Superset and a staging copy of Metabase, each connected to a non-production copy of the warehouse or to the same warehouse under a read-only test account. Select a small set of dashboards whose upstream tables you already know from reading their SQL and dataset definitions. Before the first ingestion runs, record the expected owner, charts, datasets and source tables for each one. Those expected values are your answer key. If the catalog disagrees with the answer key, the connector configuration, the ingestion filters or the source data is wrong, and that must be fixed before anyone relies on the catalog for decisions.
The first two checks cover ownership and lineage. For each dashboard, chart and dataset in the test set, confirm that OpenMetadata shows the owner recorded in Superset or Metabase, and that this owner is a person or team that still exists in your identity provider. Then compare the table-to-dashboard lineage edges with the SQL the tool actually runs. In Superset, the dataset definition and the query history are the reference. In Metabase, check both query builder questions and native SQL questions, because the two produce lineage through different paths. Where warehouse query logs are available, use them as an independent record of which tables each dashboard reads. Any edge that is missing, extra or points at the wrong table is a finding to log against the connector version you deployed.
Next, test how changes are handled. Rename one test dashboard and delete another in staging, then run ingestion on the schedule you plan to use in production. Confirm that the renamed dashboard appears under its new name, that the old name no longer appears as a live asset, and that the deleted dashboard is removed or marked as deleted, according to the behavior you configured and tested in your OpenMetadata version. Check lineage on the renamed item as well, since edges can persist while the display name changes. Confirm the ingestion schedule and metadata filters in your own settings before relying on any default, because both determine how quickly the catalog reflects these changes.
The next check tests what the ingestion account can do, because a catalog account that can also write is a second change path into your BI tools. Create a dedicated service account in Superset and in Metabase with read-only metadata access. Confirm the permissions it actually holds by attempting operations it should not be able to perform, such as creating or editing a dashboard, changing a dataset or altering a database connection. In Metabase, row and column level permissions, SSO and usage auditing are included only in the Pro and Enterprise plans, so the permission design you can enforce depends on the plan you select. On the warehouse side, grant SELECT only on the schemas the test dashboards need, then confirm that inserts, updates and DDL against those schemas fail under the same credentials.
Finally, make re-testing part of every upgrade. Rehearse Superset upgrades in staging first: back up the metadata database, run the documented database upgrade and init steps, and review UPDATING.md for breaking changes between the versions involved. Metabase runs application database migrations automatically, so back up the application database first, reduce a cluster to a single node for major upgrades because of the migration lock, and follow the documented release-by-release path if you start from a version older than 40. For OpenMetadata, rerun the full test plan after each upgrade. Version 2.0 has breaking changes to review, including rebuilt custom ingestion images for Python 3.12 and a Great Expectations migration to 1.3 before upgrading. Maintenance releases arrive frequently, so schedule a catalog retest for each release you deploy.
Common failures when cataloging Superset and Metabase dashboards
This table lists common failures when cataloging Superset and Metabase dashboards in OpenMetadata, with the likely cause and a general fix for each. Read each row as a symptom to check first, then confirm version-specific steps in the release notes for your target version. The main takeaway is that most failures come from service account permissions, mismatched table names, authentication settings or skipped upgrade preparation, so review those four areas before troubleshooting further.
| Failure | Likely cause | Fix |
|---|---|---|
| Test connection fails | Service account lacks the API or metadata permissions the connector needs in the Superset or Metabase source | Grant the connector account the metadata and API permissions its documentation lists, then rerun the connection test |
| Lineage edges missing | Table names or schemas differ between warehouse ingestion and BI metadata, so the entities do not match | Align database, schema and table naming across both ingestions, rerun ingestion, and check lineage on one dashboard |
| SSO login loops or errors | Mixed authentication, since OpenMetadata does not support SSO and basic authentication together, or a redirect URL mismatch | Use one authentication mechanism, register the exact callback URL with the identity provider, and test in a clean session |
| Superset fails to start after install or upgrade | SECRET_KEY is not set, and Superset requires a user-specified value to start | Set a unique SECRET_KEY in the configuration before startup and store it in your secrets manager |
| Metabase sign-in options missing | The plan does not include SSO or SAML, since Open Source and Starter offer Google sign-in and LDAP only | Confirm the plan on the pricing page before design, or use Google sign-in or LDAP where your plan allows |
| OpenMetadata ingestion fails after upgrading to 2.0 | Custom ingestion images were built for an earlier Python version, or 2.0 breaking changes were not reviewed | Rebuild custom ingestion images for Python 3.12, and review the 2.0 breaking changes before upgrading |
| Superset upgrade problems | Breaking changes between versions were not reviewed, or the metadata database was not backed up | Back up the metadata database, check UPDATING.md for each version step, and test the upgrade in staging first |
| Metabase upgrade stuck on a migration lock | Multiple cluster nodes contend for the application database during a major upgrade migration | Back up the application database, reduce the cluster to a single node for the major upgrade, then scale back out |
Questions buyers ask before hiring help with this integration
What drives the cost of an OpenMetadata connector project for Superset and Metabase?
Scope and environment set most of the cost. The main drivers are the number of BI instances, the number of dashboards and charts to catalog, the number of warehouses whose tables feed lineage, how identity is integrated, and how accurate lineage must be. One Superset instance on one warehouse is a small, bounded job. Several Metabase instances, dozens of dashboards and warehouses with inconsistent naming add discovery, mapping and review time. Identity work is separate from ingestion, since SSO must be configured in OpenMetadata and in each BI tool. Lineage validation takes longer when dashboards use custom SQL or native queries. A partner bills for scoping, configuration, testing and handover, while your team supplies access and decisions. Ask any quote to itemize connectors, lineage checks, identity work, staging tests and documentation, and to state which items recur, such as scheduled ingestion upkeep.
How much does the Metabase plan affect SSO for this integration?
SSO in Metabase depends on the plan you buy. According to Metabase's pricing page, SSO is included only in the Pro and Enterprise plans. The Open Source and Starter plans support Google sign-in and LDAP. The page lists Open Source as free, Starter at $100 per month or $90 per month billed yearly with 5 users included, Pro at $575 per month or $517.50 per month billed yearly with 10 users included, and Enterprise priced by quote starting at $20,000 per year. Metabase's documentation indicates that JWT, OIDC and SAML setups, including those for Okta, Entra ID and Keycloak, require Pro or Enterprise. Confirm current figures on the pricing page before you budget. Plan fees recur and are separate from implementation fees, so ask your Metabase contact which tier your user count and identity provider require.
Does Apache Superset have a paid edition for enterprise features?
No, Apache Superset has no paid edition. Superset is an Apache Software Foundation project released under the Apache License 2.0, and the project does not sell a commercial tier. Its authentication options come from configuration: OAuth2 providers such as Google and Azure, custom OAuth2 servers using the code flow, and LDAP, with AUTH_ROLES_MAPPING to map groups to roles. Cost therefore comes from hosting, the metadata database, caching and workers, and the people who run them. Expect recurring operating work. The Superset upgrade documentation says to back up the metadata database, run superset db upgrade and superset init, test in staging first, and check UPDATING.md for breaking changes. Ask a partner to price that operating work separately from the initial build.
Is OpenMetadata free to use, and who supports it commercially?
OpenMetadata is released under Apache License 2.0, and Collate offers commercial support. The project is maintained by Collate, which also offers commercial enterprise capabilities and premium support. The license cost is zero, but operation is not free. You pay for compute, the database and search services, storage, and the engineers who run ingestion and upgrades. The bare metal prerequisites are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The 2.0 release also includes breaking changes, including a new llmConfiguration block for embedding credentials and a migration of Great Expectations to 1.3 before upgrading, so plan for them. If you want a commercial support contract, ask Collate what it covers. Ask DeployOpen separately for implementation, connector work and upgrades under a written scope.
How long does an OpenMetadata and BI integration project take?
Duration depends on scope and environment, and no fixed number applies. A narrow project with one Superset instance, one warehouse and existing access can be short. Several Metabase instances, many dashboards, custom identity integration and lineage validation take longer. The environment matters as well: whether OpenMetadata already runs, which deployment model you use (Kubernetes, bare metal, or Docker for local trials), and whether a staging environment exists for testing. Most engagements are fixed-scope, so the timeline and deliverables are agreed in writing before work starts. Ask the timeline to name the connectors, the number of BI instances, the lineage checks and the staging steps it covers. Also ask which steps depend on the availability of your own teams, since those waits often move the schedule.
What do we need to provide before the integration work starts?
Access, owners and standards come first. Your team typically provides read access to the warehouses and BI tools, service accounts with the permissions the connectors need, and named owners for each dashboard, dataset and domain. Naming standards for databases, schemas, dashboards and collections make lineage and search reliable, so agree them before ingestion starts. A staging environment for OpenMetadata and a test copy of the BI instances let changes be checked before production. You also need an identity decision: which provider signs users in, and which group maps to which role. Decision-makers should confirm who approves access, who reviews lineage output, and who runs upgrades after handover. Missing items often extend the timeline, so list them in the quote.
Can our team set up OpenMetadata with Superset and Metabase alone?
Yes, for a small scope, if engineers have time to work through the connector documentation. A single BI instance, one warehouse and basic login can be handled in-house using the OpenMetadata connector documentation and the Superset and Metabase documentation. A partner adds value as the scope grows: several BI instances, SSO through an identity provider that requires Pro or Enterprise in Metabase, lineage accurate enough for audit or privacy work, or upgrades across breaking changes. Be realistic about capacity. Ingestion, identity, staging tests and upgrades recur after launch, so name the person who will own each one. Ask any partner to put its scope in writing, then compare that with the time your team would spend learning the tools.
How DeployOpen scopes, delivers and supports this integration
DeployOpen plans and implements OpenMetadata with Superset and Metabase inside infrastructure you control, starting from a written scope agreed before work begins. Each engagement is planned around your data stack, deployment target and access model, and the work is documented so your own team can run it. Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers.
How we scope
- The written scope names which OpenMetadata connectors, Superset and Metabase instances, and databases are in scope.
- Scoping covers which dashboards, charts and lineage paths to catalog, and who owns each one.
- Hosting, metadata database, search and authentication choices are settled before any build starts.
How we build
- Build OpenMetadata on your chosen target, with the documented database and search prerequisites in place.
- Configure the Superset and Metabase connectors, then validate dashboards, charts and lineage reaching the catalog.
- Test ingestion runs, lineage paths and access controls, then record results in the handover pack.
How we hand over
- Documentation covers the deployment, connector configuration, scheduled ingestion and the lineage model.
- Runbooks cover credential rotation, failed ingestion and upgrade steps, including the OpenMetadata 2.0 breaking changes.
- Your team receives configuration files, access records and a walkthrough of the working system.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Superset and Metabase upgrades need backups and staging tests before each production change.
- Confirm response expectations and escalation paths in the written scope before signing.
