dbt did something rare for a data tool: what it really added to the stack was a discipline. SQL got version control, tests, documentation and dependencies, and the “analytics engineer” job title exists because of it. With around 14,000 GitHub stars, 5 million weekly package downloads and a community nothing else in the category approaches, it’s the closest thing the data stack has to a standard. Which is exactly why its merger with Fivetran deserves a clear-eyed look.
Where I stand
dbt is the easiest recommendation in this directory, with our highest G2 rating (4.7 from 209 reviews) to back it up. The only real decision is Core versus Cloud, and it’s less about features than about who runs the scheduler.
Core or Cloud, settled honestly
dbt Core is free, open source and complete as a transformation engine. What it lacks is a place to run on a schedule, a browser IDE and the hosted semantic layer. If you already operate an orchestrator (Airflow and Dagster both integrate natively), Core costs you nothing but the setup afternoon, and plenty of serious teams never leave it.
dbt Cloud starts free with one Developer seat and 3,000 successful models built a month, which is a real allowance for a solo practitioner. Starter is $100 per seat a month, covering five developer seats, 15,000 models a month and 5,000 queried metrics. Enterprise and Enterprise+ raise the caps to 100,000 models and 20,000 metrics with custom seats and custom pricing. Newer features meter separately: dbt State, for instance, bills pay-as-you-go at $0.094 a unit after a 30-day trial.
The subtlety in those caps: they count successful model runs a month, so they bite on run frequency, not project size. A modest project running hourly burns through a cap that a huge nightly project never touches. Check your schedule against the ceiling before picking a plan, because that’s the number that decides your tier.
The habits it enforces are the product
What you actually get from adopting dbt is organisational. Metrics defined once, in code, reviewed in pull requests. Tests that fail loudly before the dashboard lies quietly: uniqueness, nulls, accepted values, freshness. Documentation and lineage generated from the code itself, so the answer to “where does this number come from” is a link rather than an archaeology project. Teams feel the difference within a quarter, and it’s why the tool spread analyst-to-analyst rather than top-down.
Momentum is healthy too: 36 releases in the last 90 days and about a thousand commits, in the open.
Starting well, from someone who has watched it go wrong
The failure mode isn’t the tool, it’s the sprawl: eighteen months in, 400 models, nobody sure which are load-bearing. The teams that stay happy do a few unglamorous things early. A staging layer that does nothing but rename and type-cast, one model per source table, so raw never leaks into logic. Tests written at the same commit as the model, because “we’ll add tests later” is a lie everyone tells. A naming convention enforced in review, however arbitrary, because consistency beats cleverness. And ruthless pruning: a model nobody queries is a liability with a maintenance cost, not an asset.
On the semantic layer: it’s the right answer to metric drift, and it’s also a Cloud-side feature with per-metric caps, so treat adopting it as a plan-sizing decision rather than a checkbox. Teams on Core get most of the discipline benefit from conventions alone.
The Fivetran question
dbt Labs and Fivetran merged in an all-stock deal announced in October 2025, creating a company near $600 million in annual revenue. dbt Core remains open source, and nothing visible has narrowed. Still, two practical notes. If you’re choosing an ingestion tool, know that recommending “Fivetran plus dbt” is no longer recommending two independent vendors. And if you’re signing dbt Cloud multi-year, ask how bundling with ingestion will be priced, because a combined sales motion is the entire point of a merger like this. The hedge, as ever, is that Core plus your own orchestrator remains free and yours.
Anything instead of it?
SQLMesh is the credible challenger, with clever incremental processing and a growing following among engineers who find dbt’s run model wasteful. It’s worth a look for greenfield builds. But betting against dbt today means betting against the ecosystem: every warehouse, every orchestrator, every hire and every tutorial assumes it. Standards are hard to displace, and this one is earned.
Verdict
Adopt it if you have more than a handful of models; the only question is where it runs. Start on Core with the orchestrator you already have, or on Cloud’s free seat if you don’t have one. Move to Starter when the team and schedule outgrow it, and read your run frequency before trusting any cap. Rarely is the industry-standard choice also the honest one; here it is.