Skip to main content

dbt Mesh and Cross-Project References

Large data teams do not keep everything in one dbt project. dbdeux lets independent projects reference each other's trusted, published models, so you can split work across teams and domains without losing a single, connected view of your data. This is dbt Mesh, built into the platform.

Organization Mesh3 projects · 4 public data products
Cross-project dependencies
financedim_accountsfct_ledgermarketingdim_campaignsanalyticsexec_dashboardGreen dots are public models: the interface other projects can ref
Mesh readiness advisor (report-only)
Grouped
0%
Access declared
0%
Contracted
0%
stg_invoices→financeprivateonly referenced inside finance
fct_ledger→financepublicreferenced by analytics
dim_campaigns→marketingpublicreferenced across projects
Hand off to Atlas to draft the groups and access YAML as a reviewable changeset

Why dbt Mesh in dbdeux​

Challenge with other setupsHow dbdeux solves it
One giant monolithic project that every team edits, with slow runs and constant merge conflictsSplit into focused projects per team or domain, each owned and deployed independently
Referencing another team's models means copying code or duplicating sourcesDeclare an upstream project once and ref() its public models directly
No safe boundary between teams, so any model can be depended on and nothing can change safelyAccess modifiers (public, protected, private) define a clear public interface; only public models are shareable
Adopting mesh governance is an all-or-nothing rewriteA report-only readiness advisor and report-only CI checks let you adopt governance gradually
No company-wide picture of how projects connectAn Organization catalog view shows every project, its public data products, and cross-project lineage in one place

Declaring Upstream Project Dependencies​

On the catalog's Mesh tab, the project dependencies card lets you declare which upstream projects your project builds on. For each upstream you add, you can browse its public interface: the models it marks with access: public, drawn from that project's production manifest.

Declaring a dependency is pure metadata. Nothing about how either project runs changes until you actually add a cross-project ref(), so you can map out your intended architecture safely before writing any code.

Cross-Project References​

Once an upstream dependency is declared, you can reference its public models from your own models. At run time, dbdeux resolves those references against the upstream project's production manifest, so your project builds against the trusted, already-deployed version of the other team's data rather than a work-in-progress copy.

  • Only models the upstream team marked access: public can be referenced, so private and protected models stay internal
  • References resolve to the upstream's production relations, so you always build on stable, published data
  • Because resolution uses the upstream production manifest, you do not need a copy of the other project's code to build against it

Organization Catalog​

The catalog's Organization tab is a company-wide view across every project you can see:

  • Every project, with its model count and how many public data products it exposes
  • Cross-project lineage edges showing which projects depend on which
  • Search across projects and public models to find the right upstream to build on
  • Expand any project to see its upstreams and its dependents at a glance

This turns a sprawl of separate projects into one connected map, so anyone can understand how data flows across the whole organization without opening each project individually.

Mesh Readiness Advisor​

Adopting mesh governance can feel daunting on an existing project. The Mesh readiness advisor on the Mesh tab makes it incremental and low-risk. It is entirely report-only: it never changes your code.

  • Adoption tiles show what share of your models are grouped, have a declared access modifier, and are contracted
  • Inferred domains group your models by how they actually consume each other, so natural boundaries become visible
  • Per-model suggestions propose a group and an access modifier for each model, with a plain-language reason (for example, "referenced across projects" suggests public, while "only referenced inside this project" suggests private)
  • Atlas handoff: when you are ready to act on the suggestions, hand them to Atlas to draft the groups and access YAML as a single reviewable changeset. Nothing is applied until you approve it

Mesh Governance in CI​

Slimmer CI includes a report-only Governance tab on each pull request run detail. It surfaces mesh governance gaps for reviewers to consider, without blocking the pull request:

  • Models that are missing a group
  • Models whose declared access does not match how they are actually consumed
  • The group owner responsible for each set of models

Because these checks are advisory, teams can raise the bar on governance over time instead of being forced to fix everything at once. See Slimmer CI for more.

  • Atlas Catalog - browse governance metadata, groups, and access on every model
  • Slimmer CI - report-only mesh governance checks on pull requests
  • Organizations - how projects and teams are structured