dbt Packages vs Mesh

Les packages dbt et dbt Mesh résolvent des problèmes différents, bien qu’ils se chevauchent aux marges. La confusion est compréhensible — les deux impliquent le partage de code ou de données dbt entre projets. La distinction est fondamentale : les packages partagent de la logique, Mesh partage des produits de données.

Packages : partage de code

Quand quelqu’un installe votre package, il obtient l’intégralité du code source — macros, modèles, tests. Le code s’exécute dans leur projet et se compile contre leur warehouse. Le runtime dbt de l’utilisateur traite tout comme s’il faisait partie de son propre projet.

# packages.yml — le code réside dans VOTRE projet après dbt deps
packages:
  - package: fivetran/stripe
    version: [">=0.12.0", "<1.0.0"]

Après dbt deps, les modèles et macros du package Stripe de Fivetran sont physiquement présents dans le répertoire dbt_packages/ de l’utilisateur. Quand dbt s’exécute, il compile ces modèles contre les credentials du warehouse de l’utilisateur, en utilisant les données source de l’utilisateur. L’auteur du package n’a aucune visibilité sur la façon dont le package est utilisé, quelles données il traite, ou s’il réussit.

Cas adaptés au modèle de package :

• Packages source open-source (Fivetran, Airbyte) qui transforment la sortie brute des connecteurs en modèles exploitables
• Bibliothèques utilitaires internes — macros partagées, tests génériques personnalisés, surcharges de génération de schémas
• Templates de modèles réutilisables fonctionnant dans différentes organisations
• Packages de tests génériques (dbt-utils, dbt-expectations) étendant les tests intégrés de dbt

Mesh : partage de produits de données

dbt Mesh (via dependencies.yml et les refs cross-projet) est le partage de produits de données. Les équipes référencent les modèles publiés des autres sans installer le code source. Une équipe marketing peut interroger ref('finance', 'mrt__finance__monthly_revenue') sans savoir comment ce modèle est construit, quelles sources il utilise ou quelles étapes intermédiaires existent.

# dependencies.yml — vous référencez leurs DONNÉES, pas leur code
projects:
  - name: finance
    dbt_cloud:
      project_id: 12345

-- Un modèle dans le projet marketing
SELECT *
FROM {{ ref('finance', 'mrt__finance__monthly_revenue') }}
WHERE region = 'EMEA'

Le modèle de l’équipe finance s’exécute dans le projet finance. L’équipe marketing obtient une référence de table, pas du code source. L’équipe finance contrôle l’accès via les niveaux d’accès des modèles (public, protected, private) et peut modifier leur implémentation interne sans affecter les consommateurs — à condition que le schéma du modèle public reste stable.

Mesh nécessite dbt Cloud Enterprise et les contrôles d’accès aux modèles. Il n’est pas disponible dans dbt Core ou les plans dbt Cloud Team.

Cas adaptés au modèle Mesh :

• Produits de données cross-équipe où une équipe curate des modèles que d’autres équipes consomment
• Frontières de domaines — les équipes finance, marketing, produit et plateforme possèdent chacune leurs modèles
• Contrats de données — modèles publiés avec des schémas imposés dont les consommateurs dépendent
• Grandes organisations où un projet dbt monolithique est devenu ingérable

Le cadre de décision

La distinction la plus claire : les packages sont des bibliothèques, Mesh est une API. Installer un package revient à ajouter une bibliothèque Python à votre projet — vous obtenez le code, vous l’exécutez, vous pouvez le lire et le modifier. Utiliser Mesh revient à appeler une API — vous récupérez des données via une interface définie, et l’implémentation relève de la responsabilité de quelqu’un d’autre.

Là où ils se chevauchent

La zone grise est le partage de modèles interne entre équipes. Une équipe plateforme construisant des modèles base curatés utilisés par toutes les autres équipes pourrait les distribuer sous forme :

• De package — chaque équipe installe les modèles, les exécute dans son propre projet et obtient le code. L’équipe plateforme publie des versions et les équipes mettent à niveau à leur propre rythme.
• De projet Mesh — l’équipe plateforme exécute les modèles de manière centralisée et les publie comme produits de données. Les autres équipes référencent la sortie sans exécuter la logique de transformation.

L’approche package donne aux équipes plus d’autonomie (elles peuvent épingler des versions, surcharger des configurations, voire forker si nécessaire). L’approche Mesh donne à l’équipe plateforme plus de contrôle (elles savent exactement ce qui s’exécute, peuvent imposer des contrats et modifier les internes sans bump de version).

L’outil dbt-meshify

Pour les équipes explorant Mesh, l’outil CLI dbt-meshify aide à diviser un projet monolithique en projets interconnectés. Il analyse votre DAG existant, identifie les frontières naturelles de domaines et génère les configurations dependencies.yml et d’accès nécessaires pour Mesh.

C’est utile car la partie la plus difficile de l’adoption de Mesh n’est pas la configuration technique — c’est décider où tracer les frontières de projets. dbt-meshify utilise vos relations de modèles et métadonnées pour suggérer des frontières basées sur les patterns d’utilisation réels plutôt que sur des hypothèses organisationnelles.

Ils ne sont pas mutuellement exclusifs

Une configuration dbt mature utilise souvent les deux :

• Packages pour les utilitaires partagés — macros, tests personnalisés, surcharges de génération de schémas. Chaque projet de l’organisation installe le même package utils interne.
• Mesh pour le partage de produits de données — l’équipe finance publie des modèles de revenus, l’équipe marketing les consomme sans exécuter les transformations finance.

Le pattern de package gère la réutilisation de code. Mesh gère les frontières de produits de données. Ils résolvent des problèmes de coordination différents et se complètent dans les organisations suffisamment grandes pour avoir besoin des deux.