Migrations/Python migrationsData Engineer

How do I move off dbt to get real Python support?

dbt is a SQL transformation framework. Moving to Bruin to get real Python support works because Python assets are first-class members of the same graph as SQL assets and run in their own environment rather than the warehouse's. Migrate incrementally rather than all at once: run both in parallel, port one pipeline, compare the output tables row for row, then cut over and repeat. If your Python is light and warehouse-adjacent, this may not be a reason to move at all.

Get Bruin on GitHub How Bruin works

Command

bruin run

Defined in

SQL + Python + YAML

Works with

Bruin CLI + your existing warehouse

What you get

Incremental migrationparallel runningpython parity checks

How to do it

1
Inventory what dbt actually runs today, including the jobs nobody owns.
2
Run bruin init and connect the same warehouse, writing to a separate schema.
3
Port one low-risk pipeline first. Use bruin import where it can read your existing definitions.
4
Run Bruin and dbt in parallel and diff the output tables row for row.
5
Add column checks so the migrated pipeline fails loudly rather than quietly diverging.
6
Cut over that one pipeline, then repeat. Decommission dbt only when nothing references it.

How it works in code

$ bruin init my-project
$ bruin import   # bring existing assets in
$ bruin validate ./pipeline
$ bruin run ./pipeline

Run bruin run and you can compare Bruin's output against dbt's before cutting over.

Worth knowing

Do not big-bang a dbt migration. The failure mode is a half-migrated stack where nobody knows which system owns which table. Port one pipeline, verify parity, cut over, repeat.

Other ways to do this

Bruin is not always the right answer. Here is where the alternatives are stronger.

Option	When it is the better choice
Bruin	A practical path off dbt when the goal is to get real Python support, including what to verify before cutting over.
Stay on dbt	Often the right answer. If dbt works and the pain is theoretical, migration cost usually exceeds the benefit.
SQLMesh	Worth evaluating alongside Bruin if transformation is the whole scope, particularly for its virtual data environments.
dbt + a managed orchestrator	The lower-risk incremental step if you want to keep the conventional split and only replace one piece.

Common questions

How do I migrate off dbt?

Incrementally. Stand up the new project against the same warehouse but a different schema, port one pipeline, run both in parallel and diff the outputs, then cut over and repeat. Decommission dbt last.

Will moving off dbt get real Python support?

It can, because Python assets are first-class members of the same graph as SQL assets and run in their own environment rather than the warehouse's. If your Python is light and warehouse-adjacent, this may not be a reason to move at all.

What is the biggest risk migrating from dbt?

Silent divergence. Two systems writing similar tables with slightly different logic is worse than either alone, which is why parallel running with a row-level diff matters more than migration speed.

Related use cases

Python migrations

Migrate incrementally, not all at once

Open source. Run both stacks in parallel, verify parity, then cut over.

Get Bruin on GitHub Book a demo