SQLMesh is 9x faster than dbt, with free dev environments. Fivetran-dbt merger raises lock-in concerns. Coalesce offers visual SQL. Decision framework.
Get new posts delivered to your inbox. No spam, unsubscribe anytime.
Fivetran acquired dbt Labs. Then Fivetran acquired Tobiko Data (the company behind SQLMesh). Then Fivetran donated SQLMesh to the Linux Foundation. One company now owns the dominant data transformation tool AND its strongest technical challenger. And dbt Labs separately acquired SDF Labs — absorbing it into the proprietary Fusion engine.
This matters because dbt isn't just a tool anymore. It's an ecosystem with 50,000+ teams, a combined ARR approaching $600 million (with Fivetran), and pricing decisions that increasingly push users toward paid tiers. The open-source community that built dbt's dominance is watching nervously as commercial pressures reshape the ecosystem. And for the first time, real alternatives exist that aren't toys.
I've used dbt for four years. It changed how I think about data transformation. But in 2026, the cracks are showing.
dbt's incremental models have a fundamental problem: if a model ever skips a run, there's a literal data hole that persists unless manually detected and backfilled. Schema changes via on_schema_change don't backfill historical data for newly added columns. And if you need to backfill 10 years of daily data, that means 3,650 queries with no configurable batch size.
Changed transformation logic makes it worse. Your existing data was processed with the old logic. New data gets the new logic. The result: silent divergence between historical and new records. You won't know until someone runs a report that spans both time periods and gets numbers that don't add up.
dbt's compilation handles Jinja macros and ref() / source() references, but it doesn't validate the underlying SQL. Missing columns, type mismatches, and syntax errors pass compilation and only fail at runtime. For a 1,000-model project, that means discovering errors in production — when the Snowflake bill is already running.
In 2026, production dbt projects have ballooned to 1,000+ models, 20+ engineers, and six-figure monthly cloud bills. Standard dbt + GitHub Actions setups struggle at this scale. CI runs take 30+ minutes. PR checks timeout. The feedback loop — the thing that made dbt great — breaks down.
dbt Cloud's Team plan price doubled from $50/month to $100/month per seat. An 8-seat team went from $9.6K/year to ~$31K/year — a 225% increase. And the Team plan is now capped at 8 developer seats; more than 8 requires Enterprise pricing.
The consumption-based model adds unpredictability: Team plans include 15,000 models built per month, with $0.01 per additional model. For large projects running CI on every PR, that adds up fast.
dbt Labs raised $222 million at a $4.2 billion valuation in 2022. They surpassed $100 million in revenue in February 2025. A ~40x revenue multiple creates intense pressure to grow revenue — and the open-source community is the easiest place to find it.
SQLMesh, built by Tobiko Data, is what dbt would look like if you designed it in 2024 with the lessons of running dbt in production. It's now open-source under the Linux Foundation.
The single biggest SQLMesh advantage. Creating a dev environment in dbt means materializing every model — which means running queries, consuming warehouse credits, and waiting. In SQLMesh, creating a dev environment is free. A full replica of any environment with a single command. Zero marginal cost for unchanged models.
This works because SQLMesh maintains state. It knows which models have changed and which haven't. If you modify one model in a 500-model project, SQLMesh only rebuilds that model and its downstream dependencies. dbt rebuilds everything you touch.
SQLMesh uses SQLGlot to parse and validate SQL at compile time. Missing columns, type errors, and syntax issues are caught before any query hits the warehouse. It also automatically generates column-level lineage from the parsed SQL — no manual annotation needed.
SQLMesh's interval-based approach tracks which time intervals have been processed for each model. If a run fails or skips, the missing intervals are automatically detected and backfilled on the next run. No data holes. No manual intervention.
Before applying changes, SQLMesh shows you a plan: what models will run, what changed, what's affected downstream, and whether changes are breaking or non-breaking. It automatically categorizes changes by analyzing column-level lineage — if a modified column isn't used downstream, the change is classified as non-breaking, avoiding unnecessary backfills.
On Databricks, SQLMesh is ~9x faster in execution speed AND compute cost versus dbt Core. Breaking changes are handled 1.5x faster with 1.5x less compute.
The speed difference comes from SQLMesh's state management. It knows which models changed, which intervals need backfilling, and which downstream models are affected. dbt doesn't maintain this state — every run is essentially stateless, relying on the warehouse to determine what needs rebuilding. State awareness means SQLMesh can skip work that dbt can't skip.
When Fivetran donated SQLMesh to the Linux Foundation in March 2026, it was a strategic move to address open-source credibility concerns. Founding members include Benzinga, CloudKitchens, Harness, Infinite Lambda, Jump AI, and Minerva.
Community governance means SQLMesh's roadmap is no longer controlled by a single company. For teams evaluating the Fivetran-dbt merger with concern about vendor lock-in, SQLMesh under the Linux Foundation provides a credible exit path. The source code is on GitHub, the governance is independent, and the Apache 2.0 license ensures you can use it however you want.
Whether Fivetran will continue investing engineering resources in SQLMesh now that it competes with dbt Fusion is the open question. The donation to the Linux Foundation could be a genuine commitment to open source — or a strategic way to slow down a competitor by removing dedicated commercial investment. Time will tell.
Coalesce takes a fundamentally different approach: a visual, GUI-based canvas that generates performant SQL. It's the only data transformation tool originally purpose-built for Snowflake, though it now supports Databricks and Microsoft Fabric, with BigQuery and Redshift coming.
| Feature | dbt Cloud | SQLMesh | Coalesce |
|---|---|---|---|
| Interface | Code + Cloud IDE | Code (CLI + web UI) | Visual canvas + code |
| SQL Validation | Runtime only | Compile-time (SQLGlot) | Visual + compile-time |
| Dev Environments | Materialized (costs $$$) | Virtual (free) | Visual workspace |
| Incremental Safety | Manual backfill | Automatic interval tracking | Visual lineage tracking |
| Pricing | $100/seat/month + consumption | Free (Linux Foundation) | Seat-based |
| Lineage | Schema-level | Column-level (automatic) | Column-level (automatic) |
| Best For | SQL-fluent analysts | Performance-critical pipelines | Visual learners, Snowflake teams |
Coalesce's strength: built-in scheduling, CI/CD integration, automated documentation, and version-controlled transformations — features dbt Cloud charges separately for. Their Copilot AI assistant claims to cut build time by 80%.
With $81.9 million in total funding (Series B led by Industry Ventures and Emergence Capital) and Snowflake Ventures as an investor, Coalesce has the backing to compete long-term. Their customer list includes Caesars Entertainment, TotalEnergies, and Houlihan Lokey.
The trade-off: if you live in the terminal and think in SQL, Coalesce's visual approach might feel constraining. It's built for teams where business analysts participate in transformation workflows alongside data engineers. Coalesce reported 4x ARR growth year-over-year for the fiscal year ending January 2024, suggesting the visual approach resonates with a significant market segment.
The Fivetran-dbt Labs merger (announced October 2025) creates the dominant data integration + transformation platform. George Fraser (Fivetran CEO) leads; Tristan Handy becomes co-founder and President. ~80-90% of Fivetran's customers already used dbt.
The open-source commitments: dbt Core and Fusion will continue under current licenses. Fivetran pledges to "actively maintain" dbt Core.
The community concerns are real:
Lock-in risk. One company now controls ingestion (Fivetran) and transformation (dbt). That's a powerful position — and a single vendor dependency for your entire data pipeline.
Open-source uncertainty. Critics argue Fivetran "bought the community and the brand" to control the ecosystem. With an IPO expected, commercial pressure on open-source could increase.
Fusion's licensing. The dbt Fusion engine — their big performance upgrade (up to 30x faster parsing, 2x faster compilation) — is released under Elastic License 2.0. Free to use internally but NOT open source. Companies can't offer Fusion as a hosted service. This directly threatens managed-dbt platforms like Paradime and DataCoves.
SQLMesh's future. Fivetran now owns both dbt (via merger) and SQLMesh (via Tobiko acquisition). They donated SQLMesh to the Linux Foundation, which is encouraging — but it's worth asking whether SQLMesh innovations will receive the same investment when they compete with dbt Fusion's commercial model.
Malloy is a different kind of bet. Created by Lloyd Tabb (Looker founder) at Google, it's both a semantic modeling language and a query language. Not SQL-plus-YAML like dbt. Not visual like Coalesce. A new language entirely.
Malloy automatically prevents miscalculated aggregates — the sums, averages, and counts that silently break when you join tables incorrectly in SQL. Nested data is far easier to work with than in standard SQL. And it has a VS Code extension for building models, querying, and creating visualizations in one environment.
It supports BigQuery, Snowflake, PostgreSQL, MySQL, Trino, Presto, and DuckDB. But it requires learning a new language, which limits adoption to teams willing to invest in a paradigm shift. Malloy isn't replacing dbt for existing projects — it's a bet on what comes after the SQL-plus-YAML model, if anything.
dbt Labs isn't standing still. The Fusion engine — powered by SDF Labs' Rust-based SQL compiler — addresses many of the technical complaints:
This is dbt's answer to SQLMesh's technical advantages. And on pure capability, Fusion closes the gap significantly.
But the licensing matters. Fusion is released under Elastic License 2.0 — free to use internally but not open source. You can't offer Fusion as a hosted service. Companies like Paradime and DataCoves that built managed platforms on top of dbt are directly threatened.
The philosophical shift is significant. dbt Core is Apache 2.0 (truly open source). Fusion is Elastic License (source-available but restricted). If Fusion becomes the default engine and Core becomes the legacy option, the open-source foundation that built dbt's community starts to erode. Whether that matters depends on whether you see dbt as a community project or a commercial product that happens to have an open-source component.
Stay with dbt if:
Switch to SQLMesh if:
Choose Coalesce if:
Explore Malloy if:
Keep dbt Core (not Cloud) if:
The pragmatic approach for most teams in 2026: run dbt Core for your existing models, evaluate SQLMesh for new projects, and keep a close eye on how the Fivetran merger affects dbt Cloud pricing over the next 12 months. If costs rise significantly, SQLMesh with the Linux Foundation governance model is the cleanest exit path.
If you're considering SQLMesh, the migration from dbt is structured:
# Initialize SQLMesh from an existing dbt project
sqlmesh init --dbt
# Preview the migration plan
sqlmesh plan
# Apply to dev environment (free — virtual env)
sqlmesh plan dev
SQLMesh reads dbt's YAML configs and SQL models directly. The ref() and source() functions work the same way. Most dbt projects can run in SQLMesh with minimal changes — the main work is replacing dbt-specific Jinja macros and adapting any custom materializations.
For Coalesce, the migration is more involved because you're moving from code-first to visual-first. Coalesce can import from dbt projects, but the paradigm shift means your team needs to learn the visual canvas and adopt different development workflows. Budget 2-4 weeks for a team of 3-5 to migrate a 200-model dbt project to Coalesce.
The honest assessment: migrating a production dbt project is a 2-6 month effort depending on project size, custom macro complexity, and team familiarity with the target tool. The technical migration is the easy part. The hard part is changing team workflows, updating CI/CD pipelines, retraining analysts, and maintaining confidence in data output during the transition.
Don't migrate everything at once. Start with new models in the alternative tool. Run both systems in parallel for a quarter. Migrate existing models gradually. This is how every successful migration I've seen has worked — incremental, measured, and reversible.
dbt created the analytics engineering discipline. That's a permanent contribution to the data industry. Every tool in this article exists because dbt proved that version-controlled SQL transformations are the right abstraction.
But dbt in 2026 isn't the scrappy open-source project that won hearts in 2019. It's a commercial platform with a $4.2 billion valuation, a merger with Fivetran, a proprietary Fusion engine, and pricing that's pushing smaller teams toward alternatives. The gap between dbt Core (free but increasingly feature-limited) and dbt Cloud (powerful but expensive) is widening by design.
SQLMesh is the strongest technical alternative. Virtual environments, compile-time validation, interval-based incrementals, and 9x performance improvements are not incremental improvements — they're architectural advantages. The Linux Foundation governance model adds credibility. If SQLMesh had dbt's community size, this article wouldn't exist because the choice would be obvious.
Coalesce is winning a different market: teams where SQL-only isn't enough and visual development workflows reduce time-to-value. It's not competing with dbt on technical depth — it's competing on accessibility.
My prediction: by 2028, the data transformation landscape will look like the CI/CD landscape does today. dbt will be the GitHub Actions — dominant, ecosystem-rich, but with clear commercial pressure. SQLMesh will be the self-hosted GitLab — technically superior for teams willing to invest. Coalesce will be the CircleCI — a managed experience for teams that value simplicity over control.
The Fivetran merger is the inflection point. For the first time, teams have a genuine reason to evaluate alternatives — not because dbt is bad, but because the business model around dbt is changing in ways that don't always favor the user. And the alternatives are finally good enough to be real options.
Here's what I'd actually do if I were starting a new data team today: use SQLMesh. The virtual environments alone save enough warehouse costs to justify the switch. The compile-time validation catches errors that dbt lets through to production. The interval-based incrementals eliminate an entire class of data quality issues. And the Linux Foundation governance means nobody can change the licensing on you.
If I had an existing dbt project with 500+ models and a team of 15 analysts? I'd stay on dbt Core, closely watch Fusion's licensing evolution, and pilot SQLMesh for new projects. Migration of a working system is expensive and risky. The switching cost has to be justified by real pain — and for many teams, dbt's pain points are manageable annoyances, not showstoppers.
The one thing I'm most certain about: the era of dbt-as-the-only-option is over. That's good for everyone — including dbt users. Competition makes every tool better. dbt Fusion exists partly because SQLMesh proved that compile-time validation and virtual environments were possible. Coalesce exists because dbt proved that not everyone needs to write raw SQL. The data transformation ecosystem is healthier in 2026 than it's been since dbt launched. Choose the tool that fits your team. Not the one with the most blog posts.