Highlightdbt Labs

Cross-project refs treat public models as a stable API, not a package

dbt Labs documentation on packages versus project dependencies that resolve public models through a metadata service.

dbt long supported installing other projects as packages, which pulls in full source code for macros and models. It also supports project dependencies that resolve on-the-fly refs to public models via a metadata service, so downstream teams do not parse or run upstream models. Those models are treated as an API whose maintainer guarantees quality and stability, with Enterprise prerequisites including public access and a production manifest.

Based on: Project dependencies | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt Mesh is a multi-project pattern for governed cross-team data products

2023 docs introducing dbt Mesh: cross-project refs, Catalog, groups, access, versions, and contracts for independent yet aligned teams.

The page says a single dbt project struggles at scale to coordinate stakeholders, and Mesh addresses multi-project dependencies, governance, and workflows. Mesh is a pattern, not one product: Enterprise cross-project ref, Catalog lineage, governance, groups, access, model versions, and contracts. It recommends treating models as stable APIs when coordinating across teams and outlines when multi-project architecture becomes appropriate.

Based on: About dbt Mesh | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt constraints validate table data only when contracts are enforced

Reference on platform constraints in dbt: validation on write, contract prerequisite, and uneven enforcement across warehouses.

Constraints are platform features that validate data as tables are created or updated; failed validation rolls back the operation. In dbt they apply only to table and incremental models that declare and enforce a contract with explicit column data types. Enforcement varies: some constraints block builds, some are metadata-only, and some platforms cannot define certain types at all.

Based on: constraints | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt model access is group-scoped visibility, not user permissions

Docs distinguishing model access from user access, and explaining groups that mark models private or public for ref boundaries.

The page separates “model access” from dbt user permissions: developers in a project see private models; others may depend only on public ones. Groups give models a shared owner and make interface boundaries explicit. Private access restricts which models other groups may ref; public models are the intended dependency surface, including for future multi-project collaboration.

Based on: Model access | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt model contracts enforce YAML column names, types, and constraints

Reference docs for dbt’s contract config: enforced schema match for supported SQL materializations, with type aliasing notes.

When a contract is enforced, dbt requires the model’s returned dataset to match YAML-defined column names, data types, and supported constraints. The goal is predictable columns for downstream users inside and outside dbt, because even a boolean-to-integer type shift can break queries. Support is limited to certain SQL materializations and platforms; Python models, ephemeral models, and several other resource types are excluded.

Based on: contract | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt model governance covers access, contracts, versions, and mesh refs

Overview of dbt model governance: public/private access, contracts, versions, namespaces, and Enterprise cross-project dependencies.

The page says model governance controls who can access models, what they contain, how they change, and how they are referenced across projects. Features include public/private access, contracts on column shape, versions for breaking changes, namespaces for ownership, and Enterprise project dependencies via cross-project ref. It also mentions freshness SLAs with State and lag_tolerance, plus caveats about adopting governance too early.

Based on: About model governance | dbt Developer Hub · dbt Labs

Highlightdbt Labs

Model versions treat shared dbt models like versioned APIs

dbt Mesh docs explaining model versioning versus other “version” meanings, and why producers and consumers need graceful change.

The page separates model versions (a Mesh governance feature) from dbt_project.yml and YAML property-file version fields. It compares shared dbt models to APIs where producers must change logic while consumers need stable queries. Model versioning is offered as a deliberate way to handle breaking changes without pretending the tension disappears. It also warns that governance features can harden rollbacks if adopted too early.

Based on: Model versions | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt Semantic Layer APIs put MetricFlow metrics behind governed query interfaces

dbt docs on Semantic Layer APIs: define metrics in code with MetricFlow and query governed assets from downstream tools, including via GraphQL.

The page argues that growth in the modern data stack fragments business logic across teams and tools. The Semantic Layer lets you define metrics in code with MetricFlow and dynamically generate and query datasets from dbt-governed metrics and models. It lists use cases such as BI, data quality, governance, discovery, and ML, and notes a GraphQL API for metrics and dimensions.

Based on: Semantic Layer APIs | dbt Developer Hub · dbt Labs

HighlightOpenMetadata

OpenMetadata docs cover discovery, lineage, contracts, and MCP for agents

OpenMetadata documentation hub for metadata discovery, lineage, governance, data contracts, and AI/MCP integrations.

OpenMetadata’s docs present a platform to document, discover, and govern data assets, with quick start, production, and upgrade paths. Guides span discovery, lineage, observability, data contracts, and governance; highlights include Context Center, MCP server and AI SDK for agents, new connectors, and dimensional data-quality validation.

Based on: OpenMetadata Documentation - OpenMetadata Documentation · OpenMetadata

Highlightdbt Labs

dbt exports materialize saved MetricFlow queries as warehouse tables

dbt docs on exports: run saved Semantic Layer queries via the job scheduler and write results to tables or views.

Exports run saved MetricFlow queries and write output to a table or view in the data platform, using the dbt job scheduler. They give SQL and non–Semantic Layer tools access to metric definitions as ordinary relations; running an export counts toward queried metrics usage, querying the result does not.

Based on: Write queries with exports | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt dimensions add categorical and time attributes to semantic models

dbt documentation for non-aggregatable Semantic Layer dimensions: name, type, optional expr and label.

Dimensions are non-aggregatable attributes in a semantic model—features that categorize data and typically appear in SQL GROUP BY. Each needs a unique name within the model and a type of categorical or time; optional expr and label control column mapping and downstream display.

Based on: Dimensions | dbt Developer Hub · dbt Labs

Highlightdbt Labs

dbt entities are typed join keys that link semantic models

dbt docs define entities as business concepts used as join keys—primary, unique, foreign, or natural—in the Semantic Layer.

Entities represent real-world concepts such as customers or transactions and act as join keys across semantic models in dbt’s Semantic Layer (v1.12+). Required parameters are name and type; types are primary, unique, foreign, and natural. Names must be unique within a model and may use expr; entities can also be used as dimensions.

Based on: Entities | dbt Developer Hub · dbt Labs