Skip to content
dbt-forge

dbt Mesh project setup

dbt Mesh project setup becomes relevant when one monolithic dbt project is no longer a good fit for ownership or delivery. dbt-forge supports this with the --mesh flow in init, which scaffolds multiple related dbt projects with contracts and cross-project dependencies in mind.

When to choose dbt Mesh

Section titled “When to choose dbt Mesh”

Mesh is usually worth the overhead when:

  • multiple teams own different business domains
  • release cycles need to be decoupled
  • access controls differ by project
  • cross-project interfaces need to be explicit

If a single team owns everything, start with How to scaffold a dbt project instead.

Scaffolding a Mesh setup

Section titled “Scaffolding a Mesh setup”

Use the mesh flow during initialization:

Terminal window
dbt-forge init analytics_mesh --mesh

This generates a starting structure for multiple dbt projects rather than one shared project tree. The generated setup is intended to create ownership boundaries early, before teams accumulate ad hoc dependencies.

What to review after generation

Section titled “What to review after generation”

Even with scaffolded Mesh support, teams should still review:

  • project boundaries and naming
  • access rules
  • contract expectations
  • cross-project dependency flow
  • CI and release ownership

That review is easier when the initial projects were generated from a consistent template instead of assembled manually.

Supporting commands after setup

Section titled “Supporting commands after setup”

Once the mesh scaffold exists, you can keep extending it with:

  • add project for new sub-projects
  • doctor for health checks inside each dbt project
  • update for template refreshes as dbt-forge evolves

If you are also converting legacy SQL into one of the projects, use Migrate SQL to dbt.

Next steps

Section titled “Next steps”