Fivetran dbt Merger: What Still Belongs in Your Repo

Why the ownership boundary matters more now

A merged vendor is not a problem by itself. The risk is architectural: when every layer comes from one place, nobody on your team writes down which parts are yours.

You find out during a contract renewal, a license change, or a migration to a different warehouse. At that point, logic that lived in a vendor UI is expensive to recover.

The vendor's own pitch supports drawing this line. In the September release, Chief Product Officer Anjan Kundavaram said every model, test and metric customers have built "already captures the context AI agents need." That context is exactly the asset you should hold in your own version control.

What still belongs in your repo

Use one rule: if losing it would change a number on an executive dashboard, it lives in a repo your team controls, with history and code review.

1. Model SQL and the dependency graph

Your models, macros and the refs between them are the business logic. They should build from a clean checkout with the open source distribution alone, not only inside a hosted IDE.

2. Tests and data contracts

Uniqueness, not null, accepted values and relationship tests encode what your team decided is true. Producer facing contracts belong here too, as we argued in data contracts that make producers own what they emit.

3. Metric definitions

Revenue, active customer and churn should be defined once, in code, and referenced everywhere else. This is the core of a single source of truth for analytics, and it should never exist only inside a BI tool.

4. Freshness requirements

dbt State moves freshness from the job to the model. The dbt Labs recap says each model can carry a lag_tolerance in code that says how stale it may be.

That is a good pattern. Keep the tolerance values in your repo, reviewed like any other change, even if the feature that reads them is a paid one.

5. A written source inventory

List every source, table and sync schedule your models depend on, plus the owner on each side. Connector setup can stay in the vendor console, but the dependency list cannot.

What is fine to rent

Renting is a reasonable choice for anything you can replace without rewriting logic. The test is simple: could you swap it within a quarter while keeping every model, test and metric unchanged?

Caching is the clearest case. dbt Labs says dbt State averages a 15 to 30 percent or larger cut in warehouse compute, and RxBenefits reported 59 percent lower warehouse cost on scheduled jobs.

Those are vendor and customer figures, not independent benchmarks. They are still a fair reason to rent the feature, because your models keep working if you turn it off.

If cost is the main driver, pair this with the levers in cutting data pipeline cost without breaking freshness before you change tools.

Run the exit test this week

You can check your exposure in one afternoon. Work through these in order:

1. Clone the repo on a clean machine and build it with the Apache 2.0 distribution only.
2. List every feature in your daily runs that needs a login or a paid tier.
3. Confirm every metric used on a dashboard is defined in the repo, not in the BI tool.
4. Check adapter status: as of dbt Summit, dbt Labs listed BigQuery, Databricks, DuckDB, Redshift and Snowflake as GA on v2, with Athena, Fabric and Postgres coming soon.
5. Write down who owns each source system and each freshness tolerance.

Anything that fails step 1 or step 3 is logic you do not fully own yet. Fix that before your next renewal, not during it.

Keep the logic, rent the plumbing

The merger made one vendor responsible for more of the stack. Your job is to make sure the parts that define your numbers stay in code you own, so any service around them stays replaceable.

A managed data platform should work the same way: it runs your models and pipelines, while the logic stays in your repo. Book a demo to see a managed data platform running on your own sources.