dbt projects that build fast, test what matters and survive the v2 move.
We build dbt projects on Snowflake, Databricks and other warehouses, and clean up the ones that got messy. We add tests and CI that catch real problems, and we plan the move from dbt Core 1.x to dbt v2.
1.13 is the final 1.x minor; no end-of-life date set
release watch
dbt v2 generally available16 Sep 2026
dbt Core 1.x support
connects with
in short·20-second read
We build, review and upgrade dbt projects.
That includes designing model layers, writing tests and contracts, setting up CI and deployment, and tuning slow runs on Snowflake, Databricks or another warehouse. Two things changed this year. Fivetran and dbt Labs completed their merger in June 2026, and in September 2026 the Fusion engine became generally available as dbt v2. We help teams decide when to move off dbt Core 1.x and which distribution fits.
you probably need this if
A full dbt build takes hours and nobody knows which models are the slow ones.
Tests fail so often that people merge anyway.
Each pull request rebuilds the full project since CI has nothing to compare state against.
01 Jun 2026Fivetran and dbt Labs merger completed All-stock merger, announced 13 October 2025 and closed 1 June 2026. The company operates as Fivetran + dbt Labs, with George Fraser as CEO and Tristan Handy as President. source ↗
16 Sep 2026dbt v2 generally available Fusion reached general availability and is now just called dbt. dbt OSS is the name for the fully open-source Apache 2.0 subset. source ↗
today · Oct 22, 2026
no date yetdbt Core 1.x supportdbt Core 1.13 should be the final 1.x minor. Critical fixes go on beyond the usual one-year window. No end-of-life date is set.source ↗
the story · dbt estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your dbt estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · dbt estate3 open
openA full dbt build takes hours and nobody knows which models are the slow ones.
recurringTests fail so often that people merge anyway.
blockedEach pull request rebuilds the full project since CI has nothing to compare state against.
exposure
dbt v2 upgrade planningProject structure and modelingTesting, contracts and CIPerformance and cost tuningSemantic layer and metrics
startrehearsehandover
Project review
dbt v2 readiness check
Structure, tests and contracts
Slim CI and deployment
Metrics and handover
we are here
ready to hand over
It builds on dbt v2 now, and the compiled SQL matched v1 before the switch.
Revenue is defined once, as a MetricFlow metric someone owns.
dbt v2 readiness report covering deprecations, packages and adapter support
Parallel-run comparison of v1 and v2 builds, model by model
chapter 01 · where it hurts
Why teams reach out
A full dbt build takes hours and nobody knows which models are the slow ones.
Tests fail so often that people merge anyway.
Each pull request rebuilds the full project since CI has nothing to compare state against.
chapter 02 · what we change
How we solve it
dbt v2 upgrade planning
Project structure and modeling
Testing, contracts and CI
Performance and cost tuning
Semantic layer and metrics
chapter 03 · how it runs
Our approach
Project review
dbt v2 readiness check
Structure, tests and contracts
Slim CI and deployment
Metrics and handover
chapter 04 · where you end up
What changes
It builds on dbt v2 now, and the compiled SQL matched v1 before the switch.
Revenue is defined once, as a MetricFlow metric someone owns.
dbt v2 readiness report covering deprecations, packages and adapter support
Parallel-run comparison of v1 and v2 builds, model by model
what we do
Our dbt work
5 kinds of dbt work, each run by engineers who have done it on live tenants.
A readiness check of your project against dbt v2, covering deprecated syntax, packages and adapter support, followed by a staged switch with parallel runs.
Staging, intermediate and mart layers with clear naming, sources declared once, and models sized so a change doesn't rebuild half the warehouse.
Data tests where failures matter, model contracts on shared marts, and slim CI that builds and tests only changed models on each pull request.
Incremental strategies, materialization choices and warehouse sizing reviewed against run history so jobs finish in their window.
Metrics defined once in MetricFlow and exposed to BI tools, so finance and operations stop arguing about whose revenue number is right.
capability 01 / 05in production
dbt v2 upgrade planning
A readiness check of your project against dbt v2, covering deprecated syntax, packages and adapter support, followed by a staged switch with parallel runs.
We pieced these together from dbt situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
A 1,400-model project on Core 1.8 with deprecation warnings everywhere
composite · not a client story
Beforethe situation
A dbt Core 1.8 project has grown to 1,400 models, with packages pinned long ago, warnings nobody reads and a full build that runs most of the night. The team wants dbt v2's faster parsing but can't stop shipping to migrate.
What we dothe work
We step through supported 1.x minors first and clear deprecation warnings as they appear. Then we check the project against dbt v2's change list, update or replace blocking packages, and run v1 and v2 side by side in CI on the same commits until compiled SQL and test results match.
Afterwhere you end up
It builds on dbt v2 now, and the compiled SQL matched v1 before the switch. The deprecation warnings are gone, and analysts kept merging models the whole way through.
case file 02
Finance and sales report different revenue from the same warehouse
composite · not a client story
Beforethe situation
Revenue is calculated in four marts with slightly different filters for refunds and currency. Dashboards in two BI tools read different marts, and every quarter-end starts with a reconciliation call.
What we dothe work
We trace each revenue figure back through the DAG and agree one definition with finance. It is built once as a MetricFlow metric on a contracted mart. The other marts get a dated deprecation notice, and the BI tools read the metric through the semantic layer.
Afterwhere you end up
Revenue is defined once, as a MetricFlow metric someone owns. Changing it takes a reviewed pull request. At quarter-end, finance and sales open the call with the same number.
We don't start a step until the last one has produced something you can check.
step 01
Project review
First we read the DAG, the run history, tests, packages and deployment setup. Out of that comes a list of the models costing you the most time and money.
step 02
dbt v2 readiness check
Deprecated syntax, package versions and adapter support get checked against dbt v2. We fix what we can on 1.x first. That way the actual switch is a small change.
step 03
Structure, tests and contracts
We sort out naming across staging, intermediate and mart layers and declare each source once. Marts that other teams rely on get contracts.
step 04
Slim CI and deployment
On a pull request we build and test just the models that changed, against production state. Merges deploy through your scheduler or through dbt platform jobs.
step 05
Metrics and handover
We move shared metrics into MetricFlow and leave your team a style guide and review checklist for new models.
ai on dbt
Where AI fits on dbt, and where it needs guardrails.
dbt's AI features are dbt Copilot inside the dbt platform and the dbt MCP server, which gives AI clients governed access to models, metrics, lineage and Semantic Layer queries. The remote server can't run dbt commands. The self-hosted one can. On a dev machine that helps. Anywhere near production it's risky.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
dbtdoes the work
dbt Labs publishes an official dbt MCP server, self-hosted or remote. Clients connect with OAuth or a token, and the tools they get depend on the dbt platform plan. We use service tokens scoped to one project and environment, keep command tools off in production and watch the remote limit of 5,000 requests a minute per IP.
Remote dbt MCP server
The remote server is hosted on the dbt platform, so there's nothing to install. It has Semantic Layer, SQL, metadata discovery and Administrative API tools, but it won't run dbt commands. We point analyst agents at it so their answers come from defined metrics instead of ad hoc SQL.
Self-hosted dbt MCP server
The self-hosted server (you start it with uvx dbt-mcp) can run dbt build, run and test, and it generates code. We keep it on developer machines, pointed at dev targets, and switch off the command tools with environment variables wherever they aren't needed.
dbt Copilot
The text_to_sql MCP tool uses dbt Copilot actions. If the account runs out of them, the tool stops working until the limit resets. Admins can switch AI features off, but that only hides this one tool. Before rollout we agree that policy with your data owners.
Tests and docs drafted with AI
A lot of projects have thin tests and empty descriptions. We have AI draft model descriptions and data tests from the SQL and sample data. We keep only the tests where a failure would change a decision.
How a dbt change goes from pull request to a trusted metric
Engineers change models in Git. Before merge, CI builds only what changed. dbt then compiles the project into SQL that runs inside your warehouse, and BI tools get one definition per metric from the semantic layer.
These are working documents, written against your configuration, so your team can run them without us.
report01
dbt v2 readiness report covering deprecations, packages and adapter support
yours to keep
design02
Parallel-run comparison of v1 and v2 builds, model by model
yours to keep
tests03
Slim CI pipeline that builds and tests only changed models
yours to keep
design04
Model contracts on shared marts, each with a named owner
yours to keep
design05
Run-time and warehouse cost report with incremental model fixes
yours to keep
talent and delivery · dbt
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your dbt work. The ones who've done it answer differently from the ones who've read about it.
Q1
Will you run v1 and v2 builds side by side before we cut over?
The two engines parse and compile differently. Run both on the same commits and compare the compiled SQL and test results. That's the only real proof the switch changed nothing users will see.
Q2
Which of our packages and adapters block a move to dbt v2 today?
Third-party packages and adapters often lag a new engine. The blocker list decides whether the upgrade takes a sprint or a quarter.
Q3
Do we need the full dbt distribution or dbt OSS, given our licensing policy?
dbt OSS is the Apache 2.0 subset. The full distribution adds proprietary features under the dbt Product Licensing Agreement, and legal may want to read that before engineers start relying on them.
Q4
Which tests will you add, and which existing ones will you delete?
Hundreds of not_null tests that never fail slow CI and teach people to ignore red builds. Tests belong where a failure would change a decision.
Q5
How does the Fivetran merger affect our contracts if we use both products?
Ingestion and transformation are sold by one company now. No product retirements were announced. Look at renewal terms, support channels and bundling before the next contract cycle anyway.
01Do we have to move off dbt Core 1.x now?
No. dbt Labs says 1.x keeps getting critical security and installation fixes past the normal window, and there's no end-of-life date yet. Moving still pays off with faster parsing and newer features, so we'd do a readiness check and a staged plan, without rushing the switch.
02What's the difference between dbt and dbt OSS?
They're both dbt v2 distributions on the same engine. dbt OSS is the open-source subset, under Apache 2.0. dbt is the full distribution, with extra features built from proprietary code under the dbt Product Licensing Agreement. Choose based on which of those features you need and on your licensing policy.
03Does the Fivetran merger change how we use dbt?
Not yet. Nothing in the press release retires a product. Ingestion and transformation now come from the same vendor, though, so it's worth reviewing your contracts and roadmap together.
04Can you take over a dbt project someone else built?
Yes. We start with a review of project structure, tests, run times and deployment, then agree a short list of fixes before adding new models.
05How long does a move to dbt v2 take?
It depends on project size, how many packages you use and whether your adapter supports v2 yet. Small, current projects move quickly. Large projects with old packages and deprecated syntax need a clean-up phase first. We run a readiness check before giving an estimate.
services
Related services
Projects on dbt usually end up touching one of these, so they're worth a look.
