← Back to list

Can we implement Data Mesh in dbt ?

The answe is Yes, we can implement a Data Mesh using dbt, and in fact, dbt is one of the best tools to support Data Mesh principles when…

Valentin Loghin · 2025-07-27 16:51 · 8 claps · 3.2 min read
#data-mesh #data-mesh-architecture #data-mesh-implementation #dbt #dbt-cloud
Open on Medium ↗
Wiki topics: 🔧 · Data Engineering 🏛️ · Architecture

Can we implement Data Mesh in dbt ?

The answer is Yes, we can implement a Data Mesh using dbt, and in fact, dbt is one of the best tools to support Data Mesh principles when paired with a modern data platform like Snowflake, Databricks, BigQuery, or Redshift.

✅ What Is Data Mesh (Quick Recap)?

Data Mesh is a decentralized data architecture approach where data is treated as a product, and domain teams own their data pipelines. Key principles:

  1. Domain-oriented data ownership
  2. Data as a product
  3. Self-serve data infrastructure
  4. Federated governance

✅ How dbt Supports Data Mesh

🏗️ Example Structure

Project Layout:

dbt/
├── dbt_sales/
│   ├── models/
│   ├── macros/
│   └── dbt_project.yml
├── dbt_marketing/
│   ├── models/
│   └── dbt_project.yml
└── dbt_common/
    ├── macros/
    └── dbt_project.yml
  • Each team owns their own dbt project, data models, and logic.
  • **dbt_common includes shared macros, testing templates, and governance policies**.

🧩 Key Features to Enable Data Mesh in dbt

  • Cross-project dependencies: With dbt packages, teams can import shared logic from central or other domain projects.
  • CI/CD per domain: Each domain can build/test/deploy independently.
  • Data contracts: Enforced with dbt tests and documentation.
  • Semantic Layer (Optional): Use dbt metrics (in dbt Cloud) for consistent KPIs across domains.

🛠️ Platforms to Pair With:

✅ Summary

Yes — dbt is ideal for building a Data Mesh. You can:

  • Split work across domains
  • Treat datasets as products
  • Enforce governance via tests/macros
  • Maintain autonomy and consistency at scale

✅Here’s a complete example of a Data Mesh implementation using dbt, broken down into:

✅ 1. Overall Folder Structure

data-mesh/
├── dbt_common/               # Shared macros, tests, policies
│   ├── macros/
│   ├── tests/
│   └── dbt_project.yml
├── dbt_sales/                # Domain: Sales
│   ├── models/
│   │   ├── staging/
│   │   └── marts/
│   ├── macros/
│   └── dbt_project.yml
├── dbt_marketing/            # Domain: Marketing
│   ├── models/
│   │   ├── staging/
│   │   └── marts/
│   ├── macros/
│   └── dbt_project.yml
└── dbt_analytics/            # Analytics/BI Team (optional)
    ├── models/
    │   └── reporting/
    └── dbt_project.yml

Each domain team owns its own repo or subfolder (dbt_sales, dbt_marketing, etc.).

✅ 2. dbt_common/dbt_project.yml (Shared Utility Project)

name: dbt_common
version: "1.0"
config-version: 2

macro-paths: ["macros"]
test-paths: ["tests"]

You can place:

  • Reusable macros (e.g., surrogate_key, scd2)
  • Generic tests (e.g., not_null, unique, contract_enforcer)
  • Global policy macros (e.g., naming conventions)

✅ 3. dbt_sales/dbt_project.yml

name: dbt_sales
version: "1.0"
config-version: 2

profile: your_target_profile

source-paths: ["models"]
macro-paths: ["macros"]

model-paths: ["models"]
models:
  dbt_sales:
    staging:
      +materialized: view
    marts:
      +materialized: table

packages:
  - local: ../dbt_common

➡️ Same structure for dbt_marketing, etc.

✅ 4. Example Model in dbt_sales/models/marts/fct_sales.sql

{{ config(materialized='table') }}

with orders as (
    select * from {{ ref('stg_orders') }}
),
items as (
    select * from {{ ref('stg_orderitems') }}
)

select
    orders.order_id,
    orders.order_date,
    items.product_id,
    items.quantity,
    items.total_amount
from orders
join items using(order_id)

✅ 5. Example Shared Macro in dbt_common/macros/generate_surrogate_key.sql

{% macro generate_surrogate_key(columns) %}
    {{ dbt_utils.surrogate_key(columns) }}
{% endmacro %}

Then used like this in models:

{{ generate_surrogate_key(['order_id', 'order_date']) }} as order_key

✅ 6. CI/CD for Each Domain

Each domain project (dbt_sales, dbt_marketing) can have its own GitHub Actions:

# .github/workflows/dbt.yml (inside dbt_sales repo)
name: dbt build

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'
      - name: Install dependencies
        run: |
          pip install dbt-core dbt-snowflake dbt-utils
      - name: Run dbt
        run: |
          dbt deps
          dbt seed
          dbt build

✅ 7. Governance and Contracts (Shared Test)

**dbt_common/tests/data_contract.yml**:

version: 2

models:
  - name: stg_customers
    columns:
      - name: customer_id
        tests:
          - not_null
          - unique
      - name: email
        tests:
          - not_null

✅ 8. Optional: Central Metadata & Monitoring

🔁 Summary of Data Mesh in dbt

If you liked this post, please show your support by 👏 for this story and follow my ! More to come on the subject dbt.


메타데이터
post_id
d9b38d9044e4
slug
can-we-implement-data-mesh-in-dbt-d9b38d9044e4
url
https://medium.com/@valentin.loghin/can-we-implement-data-mesh-in-dbt-d9b38d9044e4
canonical_url
https://medium.com/@valentin.loghin/can-we-implement-data-mesh-in-dbt-d9b38d9044e4
author_url
https://medium.com/@valentin.loghin
status
ok
fetched_at
2026-06-13 07:35:29