Tested, version-controlled SQL —
where it earns its place.
The dbt discipline brings version control, testing and generated lineage to your SQL transformations on warehouses like Snowflake or a Microsoft Fabric warehouse. We are Microsoft-first and use it when the stack calls for it — and we tell you honestly when a governed Microsoft Fabric semantic model already covers the need.
The dbt tool is a transformation-and-testing discipline, not a platform. We treat it that way, and we name where SQLMesh is the better fit.
Transformation Lineage
dbt · staging → intermediate → mart
Build · 5 models
48 / 48 tests passed
Who this is for
dbt consulting built around your role
Tested, documented transformations for the analytics engineers, data leaders and BI teams who own the layer between raw data and the report.
Analytics Engineer / Data Lead
The problem
You are the one holding the transformation layer together — untested SQL in warehouse views, logic duplicated across queries, and no build that would catch a broken change before it reaches a report.
What we build
A version-controlled model layer with schema and data tests on every build and generated lineage, so a bad transformation fails the build rather than a board pack.
A tested build that catches breakage before the report does
Head of Data
The problem
Transformations live in stored procedures and scheduled queries nobody documented, so when finance asks how a number was derived the answer is an afternoon of reverse-engineering.
What we build
A staging-to-mart model layer with generated documentation and lineage, plus an honest call on whether the dbt discipline fits or a governed Microsoft Fabric model already covers the need.
Any number traceable to its source, not to tribal memory
BI Manager
The problem
The same figure comes out differently depending on which query built it, so your reports get questioned on definition before anyone acts on what they show.
What we build
A single tested definition per model, referenced rather than copied, feeding a governed semantic model so one number is built once and reused everywhere.
One agreed definition per metric, built once
IT Head
The problem
The person who wrote the transformation logic has left, nothing is under version control, and every change to the warehouse feels risky because there is no history and no rollback.
What we build
Transformation logic as reviewed code under Git, with pull-request review, tests and a runbook, so the model layer is owned and supportable rather than dependent on one person.
A transformation layer your team can support after handover
The problem
Where untested SQL transformations bite
If your reports are built by SQL that nobody tests, versions or documents, these are the patterns we see. The dbt discipline exists to close them — but only where they are real.
The SQL that builds your reports is untested.
A model returns a number nobody can reconcile, and the first sign of a broken transformation is a figure that looks wrong in a board pack. There is no test that would have failed the build before the report shipped.
Nobody can trace where a number comes from.
Transformations sit in stored procedures, warehouse views and a chain of scheduled queries with no lineage. When finance asks how a figure was derived, the answer is an afternoon of reverse-engineering, not a diagram.
The models are undocumented and unowned.
The person who wrote the transformation logic has moved on. What each model does, why it exists and what depends on it lives in one head or none, so changing anything feels risky and slow.
Every change is a copy-paste of SQL nobody version-controls.
Logic gets duplicated across queries, edited in the warehouse console, and never committed anywhere. There is no history, no review and no way to roll back when a change breaks a downstream report.
What we build
A transformation layer with engineering rigour
Version control, tests and lineage around your SQL — plus an honest call on whether the dbt discipline fits or a governed Microsoft Fabric model already covers the need.
Version-controlled model layer
Replaces
SQL edited directly in the warehouse console with no history, no review and no rollback.
- Transformation logic as dbt models under Git, with pull-request review
- Staging, intermediate and mart layers so raw sources are cleanly separated from business logic
- A single definition per model, referenced rather than copied across queries
- History and rollback for every change to the transformation layer
Transformations become reviewed, versioned code — not console edits nobody can trace.
A tested transformation layer
Replaces
The broken figure discovered in a report, weeks after the model that produced it changed.
- Schema and data tests — uniqueness, not-null, accepted values, referential integrity
- Custom tests for your business rules, so a bad load fails the build instead of the board pack
- Tests run on every build, so a broken transformation is caught before it reaches a dashboard
- A record of what is tested and what is not, so coverage is a decision rather than an accident
A failing transformation stops at the build, not at the leadership review.
Generated lineage and documentation
Replaces
An afternoon of reverse-engineering every time someone asks how a number was derived.
- Model-level lineage generated from the code, not maintained by hand
- Documentation for every model and column, kept next to the SQL that defines it
- A dependency graph so the impact of a change is visible before it ships
- A searchable catalogue an analyst or auditor can trace a figure through
Any number traces back to its source through generated lineage, not tribal memory.
The honest fit call — dbt or a governed Fabric model
Replaces
A tool bought on reputation before anyone checked whether the need was already covered.
- A read of where your SQL transformation sprawl actually lives and who owns it
- Whether the dbt discipline adds rigour, or a governed Microsoft Fabric semantic model already does
- The practitioner comparison with SQLMesh where change-impact or column lineage matters
- A recommendation to not adopt where the need does not yet warrant a second modelling layer
You adopt the transformation discipline where it earns its place — not everywhere by default.
How we work
From SQL sprawl to a tested model set in six weeks
We start with the fit call — dbt or a governed Fabric model — then build the first model set for a priority reporting area, tested and documented.
01
Review — read the SQL sprawl
One to two weeks. We read where your transformation logic lives today — warehouse views, stored procedures, scheduled queries — and map what feeds which report. We establish whether the dbt discipline fits, or whether a governed Fabric model already covers the need.
02
First model set — tested and documented
Around four weeks. We build the first staging-to-mart model set for a priority reporting area under version control, with tests and generated lineage. Your team reviews real pull requests and sees the build catch a broken change.
03
Roll out and hand over
We extend the pattern to further reporting areas, wire the build into your schedule, and hand over documentation and a runbook so the model layer is owned by your team — not dependent on us or on one person.
Why MyData Insights
Why choose MDI for dbt consulting
Microsoft-first, honest about dbt
We build on Microsoft Fabric, OneLake and Power BI, and reach for the dbt discipline when the stack calls for it — typically SQL transformations on a Snowflake or Fabric warehouse. We will tell you when a governed Fabric semantic model already covers the need.
A discipline, not a tool sale
The dbt tool is a transformation-and-testing discipline, not a platform. We treat it that way — version control, tests and lineage around your SQL — rather than selling it as a second data platform you did not need.
Tested transformations by default
Every model set we build ships with schema and data tests that run on each build, so a broken transformation is caught before it reaches a dashboard rather than surfacing in a report.
Lineage you did not maintain by hand
Model-level lineage and documentation are generated from the code, so tracing a figure back to its source is a search, not an afternoon of reverse-engineering.
The practitioner comparison with SQLMesh
Where column-level lineage or change-impact analysis before a build matters, we weigh SQLMesh against the dbt discipline honestly and recommend the one that fits your warehouse and team — not a default.
First tested model set in six weeks
A version-controlled, tested and documented model set live in six weeks on a fixed scope, with a runbook your team owns — not a discovery deck to review.
Technology stack
Transformation
Warehouses
Microsoft Fabric
Testing & Lineage
Orchestration
BI & Output
Common questions
What buyers ask us
Do we actually need dbt, or does Microsoft Fabric already cover this?
It depends on where your transformation logic lives. If your team is writing SQL to shape data on a warehouse — Snowflake or a Fabric warehouse — and nobody can say which query feeds which report, the dbt discipline adds real rigour: version-controlled models, automated tests and generated lineage. If your reporting already sits on a governed Microsoft Fabric semantic model with measures defined once and reused, a lot of what dbt gives you is already there, and adding it would be a second modelling layer to maintain. We tell you which case you are in before recommending anything.
What is dbt, in plain terms?
The dbt tool (data build tool) is a transformation-and-testing discipline for the analytics layer, not a platform. It takes the SQL your team already writes, puts it under version control, and lets you build models as SELECT statements that reference each other, add tests that fail the build when data breaks a rule, and generate documentation and lineage automatically. It runs the transformation step inside your warehouse — it does not store data, move data or replace your warehouse or Power BI.
How is this different from just writing SQL views?
A pile of SQL views does the transformation but leaves you with no tests, no lineage and no record of why a model exists. Change one view and you discover what broke when a report goes wrong. The dbt discipline keeps the same SQL but adds automated testing, dependency-aware builds and generated documentation, so a change is caught in the build rather than in a board pack. The value is the engineering rigour around the SQL, not a new query language to learn.
You mention SQLMesh — why not that instead?
SQLMesh is the practitioner alternative worth naming. It handles some things well that the dbt tool historically leaned on add-ons for — column-level lineage, virtual data environments and change-impact analysis before you run a build. The dbt discipline has the larger community, more integrations and a team more likely to already know it. Neither is a default. We look at your warehouse, your team skills and your change-management needs, then recommend the one that fits — and are happy to say when neither is warranted yet.
How much does dbt consulting cost and how fast do we see something?
We work in fixed-scope, fixed-fee phases, never open-ended time and materials, and quote each phase precisely after a short review of your current SQL sprawl and warehouse. What we commit to upfront is the cadence: a first tested, documented model set live in six weeks, not a slide deck. Book 30 minutes with Amit and you will leave with a clear read on whether the dbt discipline fits, or whether a governed Fabric model is the better route.
Engagement
Free Transformation-Layer Review
Thirty minutes with Amit on your actual transformation layer: the SQL nobody tests, the models nobody owns, and whether the dbt discipline or a governed Microsoft Fabric model is the right route. No slides, no obligation.
What you get
- A read of your current SQL transformation sprawl and where it lives
- Whether the dbt discipline fits, or a governed Fabric model already covers the need
- The practitioner comparison with SQLMesh where change-impact or lineage matters
- A testing and lineage plan for your priority reporting area
- A six-week first-model plan you keep