The Same Platform, Twice
A mesh partitions work; it never deletes it. Every counter in this chapter's first widget is built from that one sentence — 15 buildable nodes stay 15, just split 7 and 8, and the arithmetic of splitting a shared thread pool into two separate ones is the whole cost story before a single line of YAML gets written.
Chapter 13 spent a whole chapter making a monolith safer — groups, access, contracts, versions. This chapter asks a different question: what does it cost to stop being a monolith at all? Everything a dbt Mesh is built from — groups, owners, access, contracts, versions, deprecation_date, cycle detection, even the two-argument ref() syntax — is open-source dbt Core, and has been since 1.6. The one thing that is not open source is the part that lets two separately-deployed projects find each other: the projects: key of dependencies.yml.
Toggle Wavelength between one project and two below. The default is the real, current graph — and it wins on every counter.
A mesh partitions work; it never deletes it. Every counter in this chapter's first widget is built from that one sentence — 15 buildable nodes stay 15, just split 7 and 8, and the arithmetic of splitting a shared thread pool into two separate ones is the whole cost story before a single line of YAML gets written.
Wavelength's own graph, as Chapter 12 left it and Chapter 13/14 handed it forward unchanged, is 23 graph nodes, 20 non-exposure, 15 buildable, 24 manifest nodes, in waves 8/3/2/2. That is the graph this whole chapter operates on — never the pre-Chapter-12 8/4/1/2. Splitting it does not delete any of the 15 buildable nodes; it partitions them. What it costs is real, and Section 1's counters are computed, not asserted: the same work, run as two projects instead of one, on Wavelength's own numbers.
- dbt Mesh
- dbt Labs’ name for multiple dbt projects, each owned by a different team, connected by cross-project ref() instead of one shared codebase. Not a product — a pattern built from Core primitives plus one Enterprise-only connector.
- The Core/platform line, precisely
- Every governance primitive is Core. What needs the platform, Enterprise tier and up, is the metadata service that hands one project’s production manifest to another project’s parse step — the projects: key. Section 4 states this exactly, with the tier badge quoted verbatim.
- t = 2s per model, 4 threads
- This chapter’s own explicit cost-model assumption, stated once and used throughout Section 1 and the wave arithmetic below. Not Chapter 3’s 14-node timing constant, and not a benchmark — a declared, labelled illustration.
- wavelength_revenue / wavelength_listening
- The two hypothetical projects this chapter designs a split into, in Section 5. Naming them here so every later section can refer to A (listening) and B (revenue) without redefining them.
| Primitive | Tier |
|---|---|
| access, contracts, versions, deprecation_date, groups | Core, since 1.6/1.9/1.10 |
| Two-argument ref(model, project=..., v=...) syntax | Core |
| The projects: key in dependencies.yml — resolving that ref across a real boundary | Enterprise or Enterprise+ (Section 4, verbatim) |
Treating "dbt Mesh" as a single feature you turn on. It is a pattern assembled from Core governance primitives you likely already have, plus exactly one Enterprise-gated connector. Budgeting for "a mesh" as one line item hides that almost all of the real work — drawing the boundary, writing contracts, coordinating versions — was already yours to do on Core, for free, and would still be worth doing even if you never buy the connector.
Before reading a single dependencies.yml example, ask which of its lines are Core and which need the platform — Section 4 is built entirely around that line.
Anchor every mesh conversation to a real, current node count — "15 buildable nodes" is falsifiable; "our project feels big" is not.
Keep asking, every time a "mesh" article makes a performance claim, whether it is describing a benchmark or an assumption — no published monolith-vs-mesh build-time benchmark exists, and this chapter does not manufacture one.
Whether your company should be organised as a data mesh at all — Conway's Law, DDD bounded contexts, the four principles, DATSIS product traits, federated computational governance — is an organisational question the Data Modeling KB answers in full, and its honest conclusion is that most companies should not. This chapter assumes that decision has already been made for you, and asks a much narrower one: given teams who already cannot get out of each other's way in one dbt project, what does splitting it actually cost and buy. Everything here is about ref(), access, contracts and manifests; nothing here will tell you how to draw a domain.
Data mesh and domain ownership — Data Modeling KBReaders arrive expecting a mesh to be a performance decision — "our builds got slow, split the project." It is an ownership decision. A mesh trades total throughput for team autonomy. If there is no second team, you have paid and bought nothing — Section 5 and Section 7 both land on exactly this.
A mesh is a set of Core governance primitives plus one Enterprise connector — and it partitions work, it never deletes it, which is the whole cost argument before a single project exists.