Bauplan vs dbt
Bauplan and dbt sit at different layers of the data stack. dbt is a transformation framework: it compiles SQL templates and delegates execution to a warehouse or query engine. Bauplan is an execution layer: it runs Python and SQL pipelines on its own serverless compute, with built-in branch isolation, transactional publication, and native support for AI agents.
Teams evaluate Bauplan alongside dbt when their transformation workloads grow beyond SQL, when they need isolation and versioning that the warehouse layer cannot provide, or when they want AI agents to operate on production data end to end.
Where Each Tool Sits in the Stack
dbt operates at the transformation layer. It defines models in SQL (or Python, in dbt-core and dbt Cloud), compiles them into queries, and sends those queries to a warehouse (Snowflake, BigQuery, Databricks) for execution. dbt does not own compute, storage, or data versioning. The warehouse handles all of that. dbt's value is in providing a structured, testable, Git-versioned workflow for SQL transformations.
Bauplan operates at the execution layer. It provides serverless compute (FaaS), an Iceberg-based data catalog with Git-style branching and commits, and a transactional publication model. Pipelines are written in Python and SQL, run on Bauplan's runtime, and write to Iceberg tables in your object storage. Bauplan owns execution, isolation, and publication. It is closer in scope to Databricks or Snowflake than to dbt.
This means Bauplan can replace the combination of dbt + warehouse for transformation workloads. It can also run alongside dbt, serving as the execution substrate underneath.
Comparison
When dbt Works Well
dbt is a strong choice when your transformation layer is SQL-dominant, your team works within a single warehouse, and your deployment model is human-driven with code review and CI/CD. Specifically:
dbt handles SQL transformations with a clean, testable, version-controlled workflow. The Jinja templating system is mature. The testing framework catches schema and data quality issues early. The community has produced a large ecosystem of packages. For teams whose pipelines are SQL models running on a warehouse, dbt provides a well-understood development workflow.
When Teams Outgrow dbt
The ICP pattern we see most often: dbt handles the SQL transformation layer well, but the stack fractures when Python, ML, or agentic workloads enter the picture.
Python workloads hit a boundary. dbt-core supports Python models, but they execute in the warehouse's Python runtime (e.g., Snowpark), which constrains library availability, compute behavior, and debugging. Teams that need Polars, scikit-learn, custom ML inference, or complex Python logic end up maintaining parallel execution environments alongside dbt. This splits the pipeline across two systems with different testing, deployment, and failure models.
Isolation is warehouse-dependent. dbt relies on the warehouse for execution isolation. In practice, this means staging schemas, clone operations, or manual environment management. There is no native concept of a branch, commit, or atomic multi-table publish at the dbt layer. Teams build workarounds: separate databases for dev/staging/prod, custom macros for schema swaps, manual cleanup after failed runs.
Agentic workflows have no safe execution path. dbt exposes metadata and lineage through its MCP server, and agents can generate dbt models. The gap is execution. An agent can write a model, but it cannot safely run that model against production, validate the output on an isolated branch, and merge the result atomically. The execution model depends on the warehouse, and the warehouse provides no transactional publication primitive. Without isolation and transactional semantics, an MCP server becomes a thin wrapper around a system that cannot guarantee safety for autonomous actors.
Cost scales with the warehouse. Every dbt model execution is a warehouse query. As workloads grow, especially with agent-driven iteration where a single task may trigger dozens of runs, warehouse compute costs grow proportionally. There is no way to decouple the cost of transformation execution from the warehouse pricing model.
How Bauplan Handles These Workloads
Python is native. Pipelines are standard Python functions with declared dependencies. Each function runs in an isolated, ephemeral container with its own runtime and packages. You can use any Python library: Polars, Pandas, scikit-learn, or custom code. SQL is supported for exploration and verification. There is no warehouse dependency for execution.
Isolation is built in. Every pipeline run operates on a zero-copy branch derived from the current state of production. The run reads production data but writes only to its own branch. If the run succeeds, changes merge to main as an atomic commit across all affected tables. If the run fails, the branch is abandoned and production remains untouched. Rollback is instant: point to a previous commit.
Agents operate through the full lifecycle. Agents branch, run, validate, and merge through the same typed Python SDK and MCP server that human engineers use. The platform enforces isolation and transactional guarantees at the infrastructure level. An agent can generate a pipeline, execute it on a branch, query the results, and publish atomically. Failed attempts leave no trace on production.
Pricing is decoupled from query volume. Bauplan uses flat monthly pricing with unlimited queries, users, and agents. Agent-driven iteration does not generate incremental cost.
Can You Use Bauplan and dbt Together?
Yes. Bauplan integrates with dbt, and teams use them together in two patterns.
dbt for SQL transforms, Bauplan for execution and isolation. dbt continues to define the transformation logic in SQL. Bauplan provides the execution runtime, branching, and transactional publication underneath. This gives dbt users branch isolation and atomic publication without changing their transformation workflow.
Gradual migration. Teams migrate pipelines from dbt to Bauplan incrementally, starting with Python-heavy or agent-driven workloads where dbt's model is most constrained. SQL-only pipelines can stay on dbt until the team is ready to consolidate.
A dbt Core integration is in development. Contact Bauplan for early access.
Migration Path
Teams have migrated production dbt pipelines to Bauplan, including through fully autonomous AI-driven migrations.
In a documented experiment, Claude Code autonomously migrated a production dbt pipeline (Google Analytics sessionization, deployed to a major warehouse) to Bauplan using Python and Polars. New framework, new language, new engine. Every table produced by Bauplan matched the dbt version exactly: same schema, same types, same data row by row. The migration took approximately 200 turns of autonomous iteration, completed in 40 minutes, and cost $15 in LLM inference. Zero manual intervention.
This was possible because Bauplan's branch isolation made the migration safe. The agent had full access to the production data catalog, but every write landed on an isolated branch. Every run was transactional. Failed attempts left production untouched. The agent iterated freely because the blast radius was zero.
Frequently Asked Questions
Is Bauplan a dbt replacement?
It can be, but it does not have to be. Bauplan sits at a lower level of the stack. It provides the execution runtime, data versioning, and transactional guarantees. dbt provides a SQL transformation framework. Teams replace dbt with Bauplan when they need Python-native execution, built-in isolation, or agentic workflows. Teams use both when dbt handles the SQL layer well and Bauplan provides the execution substrate underneath.
Does Bauplan support SQL?
Yes. Bauplan supports SQL for interactive queries, data exploration, and verification. Pipeline transformations are primarily Python functions. SQL and Python steps can be combined in the same pipeline.
Can I query Bauplan tables from my warehouse?
Yes. Bauplan tables are Apache Iceberg tables stored in your S3. Any Iceberg-capable engine (Snowflake, BigQuery, Databricks, Trino, Athena) can query them directly through catalog federation. No data is copied.
Does Bauplan work with Airflow?
Yes. Bauplan integrates with Airflow, Prefect, Dagster, Temporal, and other orchestrators. You call Bauplan functions and pipelines as orchestrator tasks. Bauplan handles execution and isolation; the orchestrator handles scheduling and workflow coordination.
What happens to my existing dbt tests?
Bauplan provides its own testing model (Expectations) that runs validation logic before publication. Schema tests, row-count checks, and data quality assertions are expressed in code and gated by the branch-merge model. Existing dbt test logic can be ported to Bauplan Expectations.
How long does migration take?
It depends on the pipeline complexity. A fully autonomous AI-driven migration of a production sessionization pipeline (4 models, warehouse-to-lakehouse, SQL-to-Python) completed in 40 minutes. Manual migrations of larger DAGs typically take days, comparable to any framework migration. Bauplan's branch isolation makes the migration itself safe to iterate on.
