EDITION-3

The Future of dbt: Where is dbt headed?

July 14, 2026

If you'd opened Reddit, Hacker News, or the dbt Slack the day the merger was announced, you would've thought someone had declared war on the data community. Some people called it the smartest move either company had ever made. Others saw it as the beginning of the end for open-source analytics engineering. Even people who didn't actively use both products had an opinion.

That kind of reaction is rare. Acquisitions happen all the time in enterprise software, and most barely register outside the companies involved. This one felt different because it brought together two companies that had quietly become foundational to the modern data stack.

For years, the pattern was simple. Fivetran moved the data, dbt transformed it and Snowflake, BigQuery, Databricks, or Redshift stored it. Your BI tool turned it into dashboards. Every layer was independent, and that flexibility became one of the defining characteristics of the modern data stack. If you wanted to swap out one tool, you usually could.

The merger changed that equation overnight.

After spending the last few days reading Reddit threads, Hacker News discussions, GitHub issues, release notes, and product announcements, I realized people weren't really debating the merger itself. They were debating what they wanted the future of data engineering to look like.

Should the modern data stack continue as a collection of best-of-breed tools? Or are we slowly moving toward integrated platforms that own larger parts of the data lifecycle?

Fivetran had a very different reputation

Unlike dbt, which built a loyal open-source community, Fivetran has always had a more complicated relationship with its users. Spend enough time on Reddit or Hacker News, and you'll notice that people respect what Fivetran does, but they don't always enjoy using it. Pricing is the loudest complaint, but it's far from the only one.

Many engineers described Fivetran as a black box. It works well until it doesn't, but when things go wrong, the experience can be painful. The Reddit post above captures that sentiment well. A customer claimed their services were shut off without warning because of a billing issue, leaving production pipelines down and facing a 24 to 48 hour reinstatement window.

Stories like this, combined with complaints about slow support, limited flexibility for custom pipelines, and the infamous MAR pricing model, explain why community discussions around Fivetran are often more about operational headaches.

If you're struggling to estimate what your Fivetran bill might look like, it's worth running the numbers with our Fivetran Pricing Calculator before your next renewal.

Try the calculator here

By the time the acquisition was announced, Fivetran wasn't entering the conversation with the same goodwill that dbt had spent years building. For many people in the community, the merger immediately raised difficult questions: what happens when one of the most loved companies in the modern data stack joins forces with one of its most criticized?

Would dbt stay genuinely open source? Would enterprise priorities eventually outweigh community priorities? Would Fivetran's pricing philosophy influence dbt? Would this become another example of vendor lock-in?

The Conversation Around dbt Moved Forward. Fivetran's Didn't.

Almost a year later, the conversation looks very different.

Interestingly, most discussions around Fivetran haven't changed much. Engineers are still talking about unpredictable MAR-based pricing, black-box connectors, limited flexibility, and whether managed ingestion platforms still justify their cost now that open-source and warehouse-native alternatives have matured.

dbt, on the other hand, is being discussed for entirely different reasons.

Instead of debating transformation, the community is talking about AI, semantic models, metadata, and what's next for analytics engineering. That shift is reflected in the roadmap. dbt Core 2.0 brought the Fusion runtime into open source, MetricFlow moved to Apache 2.0, Wizard introduced an AI-native development experience, and the company doubled down on semantic models, lineage, and business context.

The more I looked at these releases, the clearer the strategy became. dbt isn't trying to become a better SQL tool. It's trying to become the layer that gives enterprise data meaning. That's an important distinction because AI doesn't just need clean data. It needs context. It needs lineage, governance, consistent metrics, and shared business definitions before it can generate answers anyone should trust.Wondering if your data has the context, lineage, and governance AI needs?

Download our AI Readiness Checklist

That's where I think the future of dbt lies. Moving data is becoming a solved problem. Every year there are more connectors, more ELT platforms, and more ways to replicate data between systems. Understanding that data is a much harder problem, and it's one that AI makes impossible to ignore.

Whether dbt succeeds or not remains to be seen, but one thing feels clear after looking at the roadmap. The next decade of analytics won't be defined by who moves data the fastest. It'll be defined by who helps organizations make sense of it.

Until next time!

Hevo Data Pipeline

The Future of dbt: Where is dbt headed?

Fivetran had a very different reputation

The Conversation Around dbt Moved Forward. Fivetran's Didn't.

Related Posts

Buying an ETL Tool? Here's the Ultimate Guide to Making the Right Choice.

Inside Snowflake Summit 2026: What Data Teams Should Know

AI in Data Engineering: April Recap

Make better data decisions.Starting with the next one.

Make better data decisions.
Starting with the next one.