What the OpenMetadata and dbt integration covers and which method to use
Your data team has dbt models, tests, descriptions and owners, but anyone searching the catalog finds only warehouse tables with no context. The OpenMetadata and dbt integration reads what dbt already knows about your models and tests and brings it into OpenMetadata, so those assets appear next to the tables they build. The supported route is OpenMetadata's dbt ingestion path, which takes its input either from dbt Core artifacts that your pipeline produces or from a dbt Cloud project. Your first decision is which of those two sources matches how your team runs dbt today. Choose dbt Core when your own scheduler runs dbt and already writes the run output to a location you control. In that case, the ingestion job needs read access to those files, so the storage location, its retention and its access controls become part of the design. Choose dbt Cloud when jobs already run there and your team can issue a service credential with read access to the project. Ask who will own that credential, how it is rotated, and whether the ingestion job can reach dbt Cloud from your network. Either choice moves the metadata through the same OpenMetadata ingestion service.
Do not settle the method from memory or from this page alone. Before you commit, confirm the exact method, the list of artifacts the connector reads, and the dbt versions it supports against the current OpenMetadata connector documentation for the release you plan to deploy. Connector scope and configuration keys change between releases, so the artifact list in a blog post or an older guide may not match your version. Confirm whether test results come from run output or only from project definitions, and whether column-level metadata depends on a catalog artifact. The official OpenMetadata sources are listed in the resources section of this page. Also confirm the version pairing for your ingestion workers. The OpenMetadata 2.0 release notes list breaking changes that affect ingestion, including rebuilt custom ingestion images on Python 3.12. If your team builds its own ingestion images, the connector and its dependencies must be tested together before you upgrade the server.
Plan for failure before the first run. If the artifact files are missing, stale or partially written, the ingestion job should fail visibly instead of quietly publishing an older view of the project. Ask the team to define which dbt run produces the artifacts that feed the catalog, and whether ingestion runs after every production build or on a fixed schedule. Record the answer in the design, because a schedule that runs before dbt finishes will show the previous day's models and tests as current. Finally, decide where the source of truth for descriptions and owners lives. If descriptions are written in dbt, the catalog should display them and the team should avoid editing the same fields by hand in OpenMetadata, since the next ingestion run can overwrite manual changes. Agree on this rule with the data owners before the integration goes live.
What you need before connecting dbt to OpenMetadata
The dbt connection depends on four pieces working together: an OpenMetadata deployment, the warehouse dbt builds into, access to dbt artifacts, and a network path for the ingestion runner. Confirm each one before writing connector configuration, because most delays come from access and networking rather than from the connector itself.
OpenMetadata deployment target
Decide whether OpenMetadata runs on Kubernetes, on bare metal or in Docker for a trial. Bare metal requires Java 21, a supported database (MySQL 8.0.42 or later, or PostgreSQL 15 or later) and Elasticsearch 9.x or OpenSearch 3.x. Minimum server sizing is 2 vCPUs, 4 GB RAM and 20 GB storage, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Confirm the target version against the deployment docs before you size anything.
Warehouse connection dbt builds into
dbt writes models, tests and documentation into a warehouse that OpenMetadata must also connect to, so the same tables appear in both places. Identify the target warehouse, the database, schema and role dbt uses, and whether OpenMetadata's warehouse connector can read the same objects. Mismatched names between dbt sources and warehouse tables are a common cause of unlinked assets.
dbt Core or dbt Cloud access
Choose the source of dbt metadata: artifacts produced by dbt Core runs, or the dbt Cloud API if your team builds there. For dbt Core, confirm where manifest.json, catalog.json and run_results.json are written and who can publish them. For dbt Cloud, confirm the account, project and service token scope with the project owners. Record the dbt version in use, and confirm the artifact versions the connector supports in its current docs.
Artifact storage and delivery
Artifacts must reach the ingestion runner on a schedule, so decide where they are stored between dbt runs and ingestion. Options include object storage, a CI artifact store or the dbt Cloud API. Check artifact retention, access permissions and whether artifacts from production runs are kept separate from development runs, so OpenMetadata does not mix environments.
Network path from the ingestion runner
The ingestion runner must reach OpenMetadata's API, the warehouse and either the artifact store or dbt Cloud. Map each connection, its port and any firewall, proxy or private endpoint rules. Test name resolution and TLS trust from the runner itself, not from a workstation, because runners often sit in a different network zone than the people who configure them.
Ownership and documentation decisions
Agree with the dbt project owners which descriptions, tests and owners are authored in dbt and which are edited in OpenMetadata. Keeping dbt as the source of truth means OpenMetadata should not hold manual edits that the next ingestion run would overwrite. Confirm this decision in writing before the first sync, and name the people who approve changes to model metadata.
How dbt artifacts reach OpenMetadata
OpenMetadata can receive dbt metadata along two paths. The first reads artifacts produced by dbt Core runs from a location that the ingestion job can reach. The second pulls run metadata through dbt Cloud access. The choice depends mainly on where the dbt project runs and who controls that environment. A team that runs dbt Core inside its own data platform usually keeps the artifacts inside that platform too. A team that runs jobs in dbt Cloud usually connects OpenMetadata to the dbt Cloud account instead. Decide the path before designing storage, credentials or schedules, because each path brings a different set of dependencies into the ingestion job.
The dbt Core path depends on three things: an artifact location, a way to get artifacts there after each run, and an ingestion schedule. The location might be object storage, a shared volume or another path that the ingestion runner can read. Whoever owns the dbt job must make sure artifacts are written to that location as part of the run, not left on a developer's workstation. The ingestion schedule then needs to run after the dbt job finishes, or the catalog will show the previous run. Confirm in the OpenMetadata dbt connector documentation which artifact files it reads, which formats it accepts and which storage types it supports before you fix the layout.
The dbt Cloud path depends on a different set of inputs. The ingestion job needs network access from the runner to the dbt Cloud API, an account identifier, a project scope and an API token with the minimum read permission the connector requires. Store that token in the secrets manager that your ingestion framework uses, rotate it under your normal policy and record which service account owns it. Confirm the exact permission scope, the account identifiers the connector expects and any limits on run history in the connector documentation. Then set the ingestion schedule so that it follows your dbt Cloud job timing, not a fixed clock time chosen for convenience.
Several risks apply to both paths. Stale metadata is the most common: the catalog looks current while models, tests and descriptions have changed in dbt. Reduce that risk by linking the ingestion schedule to the end of the dbt run, by recording the run identifier in OpenMetadata where the connector supports it, and by alerting on ingestion failures. Restricted or air-gapped networks may rule out the dbt Cloud path entirely, which makes Core with internal artifact storage the practical route. Before you decide, ask your dbt administrator where the project runs, which network egress rules apply and who will own the schedule after go-live.
How to set up the OpenMetadata dbt integration step by step
This sequence connects a dbt project to OpenMetadata so that models, tests, descriptions and owners appear on the warehouse tables they build. Each step closes with a check you can run in the OpenMetadata interface, so a problem surfaces before the next step begins. Confirm field names and artifact options against the connector documentation for the version you run.
Confirm the warehouse service and its tables
The dbt connector attaches models to tables that already exist in OpenMetadata, so start by checking that the target warehouse service is registered and its metadata ingestion has completed. Open the warehouse service and confirm that the schemas and tables your dbt project builds are listed. Note the service name exactly as it appears, because the dbt service will reference it. Done when a table your project builds opens with its columns and schema visible. If it does not appear, fix the warehouse ingestion first, since dbt results have nowhere to attach.
Create the dbt service and link the warehouse
Add a dbt service in OpenMetadata and select the warehouse service from the previous step as the service it describes. Give the dbt service a name that tells your team which project it covers, because one OpenMetadata instance may hold several dbt projects. Review the connection form and the artifact source options your version offers before saving. Done when the service appears in the services list with its connection configured and no validation error. The platform team usually owns this step, and the dbt project owner should confirm the name and scope.
Choose and expose the dbt artifact source
Decide where OpenMetadata reads dbt output. With dbt Core, the connector reads artifacts such as the manifest, catalog and run results files that dbt writes to its target directory. Those files must sit in a location the ingestion runner can reach, such as a shared object storage path or a mounted volume you control. With dbt Cloud, provide the access the connector needs and confirm the project and job scope. Test reachability from the ingestion runner itself. Done when a connection test succeeds and the runner can list the expected artifact files.
Set the ingestion schedule after artifacts refresh
Schedule dbt ingestion to run after your dbt build or docs generation finishes, so the connector does not read artifacts from a previous run. Align it with warehouse metadata ingestion, which should complete first so that dbt models can link to tables already cataloged. Agree the cadence with the data team based on how often models change and how current the catalog needs to be. Record the schedule and its owner in your runbook. Done when the pipeline shows the chosen schedule and a next run time that follows your build.
Run the first ingestion and review logs
Trigger one manual run of the dbt ingestion pipeline before relying on the schedule. Open the run logs and look for the counts of models, tests and sources the connector reports, along with warnings about models it could not match to the warehouse service. Unmatched models often mean that database, schema or model naming differs between dbt and the catalog. Done when the run finishes with a success status and the log shows no unmatched models in the project you expect. Keep this log with the change record, because the first run becomes your baseline.
Verify models, descriptions and dbt links
Open a table that a dbt model builds and confirm that the page links back to the dbt model, that the model description from your schema files appears, and that column descriptions match what you wrote in dbt. Check that the lineage view shows the upstream sources. Pick tables from several team projects, not only the simplest one, because matching problems often appear in nested schemas or renamed models. Done when at least one table per project shows the dbt model link and the expected descriptions.
Confirm tests, results and owners
Check that dbt tests appear as data quality results on the tables they test, and that the latest results match what dbt reported in its run output. Open the quality tab of a tested table and compare one result with your run output. Then check ownership: owners recorded in dbt metadata should appear on the table and model pages, and they should match the teams in your directory. Done when one passing test and one failing test both appear on the correct table. If owners do not carry over, confirm the owner mapping setting for your version before assigning owners by hand.
How dbt concepts map to OpenMetadata objects
This table shows where each dbt concept lands in OpenMetadata and what the team should confirm in the connector documentation for its version. Read each row as a mapping to verify in a test environment before production teams depend on it. The main takeaway is that table-level lineage and descriptions are the most predictable parts, while owner fields and column-level detail need explicit checks.
| dbt concept | OpenMetadata object | Confirm before relying on it |
|---|---|---|
| dbt models | Tables under the warehouse database service, grouped by database and schema | How database, schema and table names are matched to existing warehouse entities for your connector version |
| dbt tests | Data quality tests attached to the related table or column | Which dbt test types are imported, and whether only definitions or also run results are carried over |
| dbt descriptions | Table and column descriptions | Whether a later ingestion run overwrites descriptions edited in the OpenMetadata interface |
| dbt owner and meta fields | Ownership, plus custom properties or tags where configured | Which meta keys are read, how owner values match users or teams, and whether unmatched owners are created |
| dbt lineage | Table-level lineage edges from upstream sources and models to downstream models | Whether dbt sources link to existing source tables and how lineage behaves when a model is renamed |
| Column-level lineage | Column mappings where the connector emits them | Expect limited coverage; confirm which transformations produce column edges and which do not |
| Artifact source | Metadata read from dbt Core artifact files or from the dbt Cloud API | Which artifacts each path requires, where they are stored, and the supported dbt versions for each |
Keeping docs written in dbt as the source of truth
Descriptions, owners and tests for dbt models should be edited in the dbt project, reviewed as code and carried into OpenMetadata on each ingestion run. The catalog should display what the project declares, not hold a second copy that can drift. When someone corrects a column description directly in OpenMetadata, that edit lives outside the project. The next run may overwrite it, merge it with the dbt value or leave both versions in place, depending on the field and the connector version. Stewards then see their change disappear, or see two descriptions that disagree, and the team stops trusting the catalog. Before go-live, confirm in the connector documentation for your OpenMetadata version how each dbt-sourced field is handled on re-ingestion.
The review workflow starts with a pull request to the dbt project. Reviewers check the YAML that holds model and column descriptions, the meta blocks used to set owners and tags, and the test definitions. Require that a change to any of these fields passes the same checks as a change to SQL, including the project's continuous integration run. After merge, a scheduled or triggered job builds the dbt artifacts for the merged commit and then runs the OpenMetadata ingestion against them. Decide who owns that trigger, how long the team accepts a catalog that lags the merge, and who is notified when an ingestion fails, so stale content does not persist unnoticed.
Write a short rule that separates dbt-sourced fields from catalog-native fields. Descriptions, owners and tests defined in dbt are read-only for stewards in OpenMetadata. Fields that belong to the catalog, such as glossary term links, domain assignment, certification status, data quality results and governance notes, stay editable there. If a field can be set in both places, name one of them as the owner and document it. Keep the rule in the same repository as the dbt project so that reviewers can point to it during pull requests. Revisit the list after each OpenMetadata upgrade, because the set of fields the ingestion overwrites can change between releases.
The rule needs an exception path, or stewards will work around it. If a description is wrong in production and cannot wait for the normal release cycle, the steward opens a dbt pull request the same day and the next ingestion reflects it. Log these exceptions so the team can see how often the process is bypassed. After the first full ingestion, sample several edited fields, confirm that the catalog shows the dbt value, and confirm that catalog-native fields survived the run. Also check how dbt Core artifacts and dbt Cloud job output reach the ingestion step in your setup, since timing and access differ. Ask your implementation partner to write these checks into the acceptance criteria.
Securing the dbt connection and the artifacts it carries
Connecting dbt to OpenMetadata adds two sensitive assets to your estate: a credential that reads project metadata and the artifact files that describe your models. Each card covers one control to design before the first ingestion run, from token handling to the sign-in model that catalog users will follow.
Handle the dbt Cloud API token
If you ingest from dbt Cloud, OpenMetadata authenticates with an API token issued from your dbt Cloud account. Decide which service identity owns the token, who may create or view it, and how it is rotated when people leave or projects change. Confirm with dbt Cloud documentation which token types and permissions your plan supports, and record a named owner for the token in your change process.
Protect artifact storage access
Core deployments read manifest, catalog and run results files from a location you choose. These files contain compiled SQL, model and column definitions and source details, so they reveal warehouse structure even when no table data is present. Store them with the same access controls as the warehouse, and review who can list, download or overwrite them, including automation accounts and CI runners.
Least-privilege ingestion service account
The ingestion account needs read access to the metadata it catalogs and no write access to warehouse data. Grant read privileges only on the schemas dbt builds and the metadata views the connector queries, and keep this account separate from the one dbt uses to run transformations. Ask the OpenMetadata connector documentation for the exact privileges your warehouse requires, then test them before granting broader roles.
Keep secrets out of configuration files
Ingestion configuration files are often copied into repositories, tickets and container images. Keep the dbt token, warehouse password and storage keys in a secrets manager that your platform team operates, and have the ingestion job fetch them at run time. Restrict who can read each secret, log access where the manager supports it, and confirm how OpenMetadata's ingestion workflow reads secrets in your chosen deployment.
Choose the user sign-in model
OpenMetadata documents SSO with providers including Auth0, Azure, Google, Okta, Amazon Cognito, OneLogin, Keycloak and custom OIDC providers. Select one provider, decide how roles and teams are assigned, and confirm that the provider's claims can carry that information. OpenMetadata does not support combining SSO with basic authentication, so plan emergency access and service identities before go-live.
How to test the dbt integration before teams rely on it
Before any team builds discovery, ownership or lineage habits on top of the dbt connection, run a structured test against a non-production dbt project and confirm that OpenMetadata reflects that project accurately. The goal is to find mismatches while they are cheap to fix. Treat the test as a gate: the integration goes to production teams only after each check below passes and the results are written down with the OpenMetadata version, the dbt version and the artifact source (dbt Core artifacts or dbt Cloud) recorded alongside them. Start by running metadata ingestion for the dbt service against a non-production dbt project that has a known shape. Use a project that contains a representative mix of models, tests, sources and owners, not a single toy model. Confirm that the ingestion run completes without errors in the pipeline logs and that the ingestion service account can read the artifact location you chose. If you use dbt Core, confirm which artifact files the connector reads in your configuration and that they were generated by the same build you intend to ingest. A stale manifest is one of the most common reasons catalog content and the repository disagree.
Next, compare a sample of objects field by field against the dbt project itself. Pick a set that covers each materialization type, a model with several column-level tests, a model with a description written in a YAML file and a model whose owner is set through meta configuration. For each sampled model, check the name, schema, description, tags, column descriptions, test definitions and owner in OpenMetadata against the source YAML and the compiled manifest. Keep a simple checklist with one row per sampled object. Differences in whitespace or Markdown rendering are acceptable if the meaning is unchanged. A missing owner, a dropped column description or a test attached to the wrong column is not acceptable and should block rollout until the mapping is corrected. Then trace lineage end to end. Choose one source table that feeds a dbt model, and one downstream table or view that reads from that model. Confirm that OpenMetadata shows the source table, the dbt model and the downstream table as connected in the correct direction, and that column-level lineage matches the model SQL where your configuration supports it. Check which lineage sources are active in your setup, because table-level lineage derived from dbt and lineage from query logs or OpenLineage events can disagree. Record which source produced each edge so that a reviewer can explain it later. Confirm this with the vendor documentation for your OpenMetadata release, since lineage behavior has changed across versions.
Deliberately fail a dbt test in the non-production project and rerun the pipeline and the dbt ingestion. Confirm that the failed test is visible on the corresponding table or column in OpenMetadata, that the status and timestamp correspond to the run that produced it, and that the test result is not attributed to the wrong asset. Then fix the test and confirm that the status updates on the next run. Decide in advance who receives notifications for failing tests, and check that the routing works for at least one owner. If results from dbt tests are shown alongside results from OpenMetadata's own data quality tests, confirm that a reader can tell them apart. Finally, run a re-run check. Execute the dbt ingestion twice against the same unchanged artifacts and compare the catalog before and after. Count the tables, columns, tests, owners, tags and lineage edges for the dbt service, and confirm that the second run creates no duplicate objects, no duplicate test definitions and no duplicate lineage edges. Also rename a model in a branch, rebuild, and confirm how the old entity is handled, whether it is marked, removed or left in place, and document the behavior your teams should expect. Repeat the re-run check after any OpenMetadata upgrade, because connector behavior is part of what you are validating.
Common dbt integration failures and how to fix them
This table pairs each common dbt integration failure with its likely cause, a check the team can run, and the fix. Read it from the symptom column when a dbt model, owner, or test is missing or duplicated in OpenMetadata. The main takeaway is that most failures trace back to one of three inputs: the artifacts, the service names, or the runner's access.
| Symptom | Likely cause | Check to run | Fix |
|---|---|---|---|
| Missing or stale artifacts | Manifest, catalog or run results were not regenerated, or the ingestion path points to an old target folder | Compare the timestamps of each artifact file with the last dbt run and confirm the configured path | Generate docs in the same pipeline run as the build, then ingest from that run's target folder. |
| Model under the wrong warehouse service | The database or service name used in dbt does not match the warehouse service name registered in OpenMetadata | List services in OpenMetadata and compare each name with the database value in the dbt sources and models | Align the names in the dbt configuration or the service definition, re-run ingestion, and confirm the table's fully qualified name. |
| Owners missing | The owner value sits outside the location the connector reads, for example outside the meta block if your connector version expects it there | Inspect one model's entry in the manifest and confirm where the owner key appears; confirm the expected path in the connector docs | Move the owner into the documented location in the dbt project, parse again, and re-ingest. |
| Tests not showing | The run results file came from a different invocation, or it was not passed to ingestion with the manifest | Confirm run_results.json came from the same job as the manifest and that the ingestion config references it | Run the tests and generate docs in one pipeline, pass both artifacts together, then re-ingest and check the table's quality tab. |
| Duplicate tables after a service rename | Ingestion created a new service and entities while the old service and its entities remain registered | Compare the fully qualified names of the duplicated tables and note which service each one belongs to | Choose one service as canonical, migrate or remove the other under your change plan, and keep the service name fixed in config. |
| Credential or network errors from the ingestion runner | The runner lacks the secret, the token scope, or a network route to the warehouse or the dbt Cloud API | From the runner host, test the connection to the warehouse and the dbt Cloud endpoint, and confirm the secret loads at runtime | Re-issue the credential with read-only scope, open the approved network route, and load the secret from your secrets manager. |
How much does an OpenMetadata dbt integration cost and what does it need from our team?
What drives the cost of an OpenMetadata dbt integration?
The main cost drivers are the number of dbt projects, whether dbt artifacts are already stored where OpenMetadata can read them, whether you run dbt Core or dbt Cloud, how many warehouses feed the same models, how identity is configured, and how much testing you want covered. Each one changes the number of connections to build, the mapping work between dbt models and warehouse tables, and the validation needed before go-live. One dbt Core project that already publishes artifacts to storage is a small job. Ten projects across two warehouses, dbt Cloud, custom ownership rules and SSO is a much larger one. Ask the provider to show which drivers are priced into the quote and which are assumed.
Is the dbt integration cost one-time or recurring?
Setup is one-time. It covers scoping, building the dbt metadata ingestion, mapping owners and descriptions, and validating results in the catalog. Recurring work includes keeping ingestion schedules running, investigating failed runs when dbt projects change, reviewing new models and tests, and applying OpenMetadata maintenance releases. Upgrades to a new major version need separate planning, because OpenMetadata 2.0 includes breaking changes that affect ingestion images and credentials. Ask the quote to split setup, recurring support and upgrades into separate line items, and ask whether ongoing support is offered as a retainer or billed per request.
What does the dbt integration need from our data team?
The data team owns the dbt side of the work. They need to confirm which projects and environments should appear in the catalog, decide where artifacts from each run are published, and agree that descriptions, tests and owners stay authored in dbt as the source of truth. They also name domain and ownership contacts, review how models map to warehouse tables, and sign off on the test results shown in OpenMetadata. Expect analytics engineers to spend time during discovery and validation. Someone should be able to explain model naming conventions, schema change practices and which dbt tests are considered business critical.
What does the dbt integration need from our platform team?
The platform team provides the runtime and access. OpenMetadata documents production deployments on Kubernetes and on bare metal. Its bare metal documentation lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The documented minimum server size is 2 vCPUs, 4 GB RAM and 20 GB storage, and the database and search services each need at least 2 vCPUs, 2 GB RAM and 30 GB storage. Plan capacity above these minimums for your data volume and confirm it. The platform team also handles network paths to warehouses and artifact storage, secrets, SSO configuration, backups and the scheduler that runs ingestion.
Can our internal team implement the dbt integration alone?
Yes, if the team has the skills and time, and the scope is bounded. An internal team that already runs dbt, operates Kubernetes or a similar platform, understands metadata ingestion and can own upgrades is well placed to do it. Gaps usually appear in three areas: ownership mapping across many projects, secrets and identity setup, and validation that the catalog matches what dbt built. Ask who will handle the first breaking upgrade and who will respond when ingestion fails overnight. If those answers are unclear, a fixed-scope engagement can cover the build while your team takes over operations.
What should a written fixed-scope quote for this integration include?
Ask for a quote that names each dbt project and environment in scope, the artifact method and storage location, whether you use dbt Core or dbt Cloud, each warehouse connection, the identity method, and which objects sync, such as models, tests, descriptions and owners. It should describe the testing and acceptance steps, the handover items including documentation and runbooks, the responsibilities on your side such as access grants and named contacts, and what is excluded. Request separate line items for setup and for recurring support or upgrades, plus the assumptions behind any timeline. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Does running OpenMetadata itself add a license cost?
OpenMetadata is released under the Apache License 2.0, so the open-source software carries no license fee. Its maintainer, Collate, offers commercial enterprise capabilities and premium support as separate options. Your costs are the infrastructure for the application, database and search services, staff time, and any support contract you choose. Before designing around a specific feature, confirm with Collate whether it is available in the open-source release or only in the commercial offering.
How DeployOpen scopes, delivers and supports the OpenMetadata dbt integration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenMetadata and dbt, models, tests, descriptions and owners reach the catalog through an agreed artifact path, and the documentation written in dbt stays the source of truth. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope names the dbt source: Core artifacts, dbt Cloud, or both, with the versions in use.
- Scope records where dbt artifacts are stored, which OpenMetadata entities they feed, and who owns each dataset.
- Ongoing support can be agreed as a retainer alongside the initial integration, with its terms written into the scope.
How we build
- Configure the dbt ingestion from manifest, catalog and run results, then test the mapping on a non-production copy.
- Map dbt tests, owners and column descriptions to OpenMetadata test cases, ownership and glossary fields, and check each one.
- Set up the artifact store and scheduled sync so catalog updates follow each dbt run, with failed loads alerted to operators.
How we hand over
- Document the artifact flow, connection settings, field mappings and sync schedule in a runbook your team keeps.
- Walk through the dbt-to-catalog workflow with the data engineers who will edit models, tests and descriptions.
- Agree the source-of-truth rule in writing: descriptions are edited in dbt and synced into OpenMetadata on each run.
How we support
- Plan upgrades of OpenMetadata and dbt versions, checking the OpenMetadata 2.0 breaking changes against your setup.
- Review failed syncs and catalog drift under an optional retainer, with support terms agreed in writing.
- Confirm the dbt access model and credential rotation with your security team before go-live and at each review.
