SQLMesh, shipped when
the stack actually calls for it.
SQLMesh runs your SQL transformation layer with virtual data environments, automatic column-level lineage and CI that rebuilds only what a change touches. We ship it for teams whose transformation CI is slow, whose environments drift, and who want lineage the tool keeps current.
We are Microsoft-first. Having shipped both dbt and SQLMesh, our starting view is honest: SQLMesh and dbt solve the same job differently, and on some teams a governed Microsoft Fabric model already covers the need. See where it fits alongside dbt and the wider modern data stack.
Virtual Environments
SQLMesh plan · build once, promote
Column-level lineage
Who this is for
SQLMesh consulting built around your role
Transformation-layer work for the people who own the CI, the lineage and the compute bill — the problem each one lives with, and what SQLMesh changes for it.
Analytics Engineer / Data Lead
The problem
You spend more time waiting on CI than writing models, because every pull request rebuilds a whole schema to test one change, and staging never quite matches production when you go to reproduce a bug.
What we build
SQLMesh virtual environments that build only the models your change touches, with change-aware CI that rebuilds the diff rather than the warehouse — on Microsoft Fabric, Snowflake or SQL Server.
CI that rebuilds the diff, not the whole schema
Head of Data
The problem
When the business asks where a figure comes from, the answer takes a day of reading SQL, and a column rename upstream keeps breaking a Power BI dataset that passed review clean.
What we build
Automatic column-level lineage derived from your SQL, so the downstream blast radius of a change is visible before merge and any figure traces back to its source column.
Column-level lineage kept current by the tool
DataOps / Platform Engineer
The problem
Per-developer environments are separate physical copies that drift, cost compute to rebuild, and turn every merge into a gamble on whether staging still reflects production.
What we build
Virtual environments where staging is the same physical data as production plus your diff, promoted rather than rebuilt — so drift stops being a class of incident.
No staging-versus-production drift to chase
IT Head
The problem
Warehouse compute keeps climbing and you cannot tie it to value, because CI rebuilds far more than each change needs and nobody owns the transformation layer after the last contractor left.
What we build
A change-aware CI setup that maps compute to real change, plus documented, owned SQLMesh models your team can maintain — or an honest call that your Microsoft Fabric model already covers it.
Warehouse compute tied to actual change
The Problem
What sends teams looking past the dbt default
None of these are reasons to switch on their own. Together, on a large SQL transformation layer, they are the case for virtual environments and column-level lineage — and the case we test honestly against your setup.
CI is slow and the bill keeps climbing.
Every pull request rebuilds far more of the warehouse than the change touches. A one-model edit triggers a full-schema rebuild, so CI takes twenty minutes and the compute line on the warehouse invoice rises every quarter without the data getting any better.
Staging and production quietly drift apart.
Each developer environment is a separate physical copy that is built once and then left to rot. By the time a change reaches production, staging no longer matches, and the bug you could not reproduce was an environment-drift bug all along.
Transformations break on deploy, not in review.
A column rename three models upstream passes review because nobody could see the full downstream blast radius. It breaks a Power BI dataset in production instead — the lineage that would have caught it lived in someone's head, not in the tool.
Nobody can answer "where does this column come from".
When finance queries a figure, tracing it back through the transformation layer is a manual read of SQL files. Column-level lineage is exactly the question the business asks most, and the default setup cannot answer it without a separate cataloguing effort.
What we build
Where SQLMesh earns its place
Four pieces of work. Three are what SQLMesh does well; the fourth is the honest comparison that decides whether you need it at all.
Virtual data environments
Replaces
The per-developer physical copies that are built once, drift from production, and make branch testing expensive.
- A branch environment builds only the models your change touches — the rest are views over production tables
- Staging is the same physical data as production plus your diff, so drift stops being a class of bug
- Promote a validated environment to production rather than rebuilding it a second time
- Cheaper CI because a pull request no longer rebuilds a whole schema to test one model
Branch-per-change testing at a fraction of the compute, with no staging-versus-production drift.
Automatic column-level lineage
Replaces
The manual read of SQL files — or a separate cataloguing project — every time someone asks where a number came from.
- SQLMesh parses your SQL and derives column-level lineage without hand-maintained documentation
- See the full downstream blast radius of a column change before you merge it, not after it breaks a report
- Trace any figure in a Power BI dataset back through the transformation layer to its source column
- Lineage lives in the tool and stays current with the code, rather than in a diagram nobody updates
The "where does this column come from" question gets a straight answer, kept current by the tool.
Stronger CI than the dbt default
Replaces
The full-schema rebuild on every pull request and the slow, expensive CI run that comes with it.
- Change-aware plans that rebuild only the models a diff actually affects
- Breaking-versus-non-breaking change detection surfaced in the plan before merge
- Column-level impact shown in review, so a rename is caught in CI rather than in production
- A CI run that maps to real cost — you rebuild what changed, not the whole warehouse
CI that catches breaking changes at review time and stops rebuilding models a change never touched.
Honest tool selection — SQLMesh, dbt or Fabric
Replaces
The assumption that a new transformation tool is the answer when a governed Microsoft Fabric model may already cover the need.
- A straight comparison of SQLMesh, dbt and a governed Microsoft Fabric model for your team and stack
- Where SQLMesh environments and lineage genuinely help — and where they add a tool for no gain
- Where a medallion model on Microsoft Fabric with Microsoft Purview lineage already covers governance
- A recommendation you can act on, not a tool we were always going to sell
You adopt SQLMesh where it earns its place — and keep what you have where it already works.
How we work
From a CI read to a first production model in 6 weeks
We start by reading how your CI and environments actually run. Only then do we recommend SQLMesh, dbt or leaving the model on Microsoft Fabric — the tool follows the evidence, not the other way round.
01
Review — read your CI and environments
Two weeks. We read how your transformation CI actually runs, what it rebuilds on each change, and how your environments are built. We map the model count, the slow paths and where drift creeps in — then compare SQLMesh, dbt and a governed Fabric model for your case.
02
Prototype — first model in a virtual environment
Two weeks. We bring one real transformation into SQLMesh, stand up a virtual environment, and prove column-level lineage and change-aware CI against your warehouse. You see the CI cost and the lineage on your own data, not a demo.
03
Roll out — migrate the layer your team will own
Two weeks to first production model, then phased. We migrate the transformation models that benefit, wire CI into your pull-request flow, and hand over documentation so your team maintains it. Where a model is better left on Fabric, we leave it there.
Why MyData Insights
Why choose MDI for SQLMesh
Microsoft-first, tool-honest
We build on Microsoft Fabric and OneLake by default, and reach for SQLMesh when the stack calls for it — virtual environments, column-level lineage or cheaper CI. We will tell you when a governed Fabric model already covers the need.
We have shipped both dbt and SQLMesh
The comparison you get is a practitioner view from delivering both, not a vendor pitch. We name where SQLMesh environments and lineage genuinely help and where dbt or Fabric is the better fit for your team.
Environments and CI are the point
The reason to adopt SQLMesh is concrete: build-once virtual environments, change-aware plans, and CI that rebuilds only what a diff affects. We set those up against your warehouse, not a sample project.
Column-level lineage, kept current
Lineage derived from parsing your SQL, so the blast radius of a change is visible before merge and any figure traces back to source — no separate cataloguing project to maintain.
Models your team can own
Every migrated model ships with CI wired into your pull-request flow, documentation and a handover, so the transformation layer does not become the orphaned code nobody can support.
First working model in six weeks
A SQLMesh model live in production on a fixed scope within six weeks, proven on your own data — not a discovery deck to review.
Technology stack
Transformation
Warehouses
Lakehouse & Storage
CI / CD
Governance & Lineage
BI & Output
Common questions
What buyers ask us
We already run dbt. Why would we move to SQLMesh?
Only if the pain is real. SQLMesh and dbt do the same job — version-controlled SQL transformations — differently. The reasons teams switch are concrete: virtual data environments that build once and get promoted rather than rebuilt, automatic column-level lineage from parsing your SQL, and a CI run that only rebuilds the models a change actually affects. If your dbt CI is slow and expensive and you keep rebuilding whole schemas to test one model, that is the case for SQLMesh. If it is not, we say so.
What are virtual data environments and why do they matter?
A virtual environment in SQLMesh is a named view layer over already-built tables. When you open a branch, SQLMesh builds only the models your change touches and points the rest at the existing production tables through views — so a staging environment costs a fraction of a full rebuild. The payoff is cheaper CI and no environment drift, because staging is the same physical data as production plus your diff, not a separate copy that quietly falls out of sync.
Is SQLMesh better than dbt?
Neither is better in the abstract — they weight different things. After shipping both, our practitioner view is that SQLMesh is stronger where environments, column-level lineage and CI cost are your bottleneck, and dbt is stronger where you want the larger ecosystem, the wider hiring pool and the packages built around it. We pick per team and per stack, not per preference. On some engagements the honest answer is that a governed Microsoft Fabric model already covers what you were about to solve with either tool.
We are on Microsoft Fabric. Do we even need SQLMesh?
Often not. A governed Microsoft Fabric model with a proper medallion layout, lineage in Microsoft Purview and Power BI on Direct Lake already covers lineage and governance for many teams. SQLMesh earns its place when you have a large SQL transformation layer you want to keep in code, a genuine need for cheap branch-per-change environments, and a team that will maintain it. We would rather tell you the Fabric model is enough than sell you a tool you do not need.
What does an engagement look like and how much does it cost?
We work in fixed-scope, fixed-fee phases, never open-ended time and materials. It starts with a review of your transformation CI and environments, a straight comparison of SQLMesh, dbt and a governed Fabric model for your team, and a lineage and CI plan. The fee is quoted after that review, once we have seen your warehouse, your model count and how your CI actually runs. What we commit to upfront is the cadence: a first working SQLMesh model in production within 6 weeks, not a slide deck. Book 30 minutes with Amit and you will leave with the shape of the engagement.
Engagement
Free Transformation-Layer Review
Thirty minutes with Amit on your actual transformation layer: how your CI runs, where your environments drift, and whether SQLMesh, dbt or a governed Microsoft Fabric model is the right call for your team. No slides, no obligation to proceed.
What you get
- A read of how your transformation CI and environments actually run
- A straight comparison of SQLMesh, dbt and a governed Fabric model for your team
- A column-level lineage and CI plan for your transformation layer
- Where SQLMesh virtual environments would cut CI cost — and where they would not
- A 6-week plan to a first working SQLMesh model in production, which you keep