Git for Lakehouse
Git for the lakehouse means applying branch, commit, merge, and rollback to your data, at the execution layer over the whole dataset environment, not at the row or table level. You branch production, run a pipeline against the branch, and merge it back atomically, the same mental model as Git, but for a lakehouse of Apache Iceberg tables. Bauplan is the execution layer for AI-generated data changes: it makes this the default way pipelines run.
TL;DR
- Git for the lakehouse applies branch, commit, merge, and rollback to data at the execution layer.
- You branch production, run a pipeline in isolation, and merge atomically, or discard.
What "Git for the Lakehouse" Means: Branch, Commit, Merge, Rollback at the Execution Layer
Git gave developers a model for code: branch to work in isolation, commit to record a change, merge to publish, roll back to undo. Git for the lakehouse brings that model to data, but with an important scope. In Bauplan, a branch represents an isolated execution environment spanning the datasets involved in a pipeline run, rather than a single table or snapshot viewed in isolation. When you branch, you get an isolated copy of production to run pipelines against. When you merge, the results publish atomically. When you roll back, you return the environment to a prior commit. Branching happens at the execution layer over the lakehouse, not at the row or table level, which is what separates it from storage-only or catalog-only versioning.
Data as Code Version Control: Beyond File Artifacts to Transactional Execution
"Data as code" often means versioning data files alongside code, the way DVC tracks artifacts. That is useful for reproducibility, but it versions files, not the execution that produces them, and it does not make publication transactional. Git for the lakehouse extends the idea past file artifacts: the version captures the resulting state of the dataset together with the validated execution that produced it. You get code-like workflow over data, with the execution and the transactional guarantee included rather than left to other tools.
Comparison
Frequently Asked Questions
Can I use git to track changes in large data tables safely?
Not git itself, but the git model applied to data. Git is built for text files and does not scale to large data tables. Git for the lakehouse brings the same operations, branch, commit, merge, rollback, to your data at the execution layer. In Bauplan you branch production with a zero-copy operation, run changes on the branch in isolation, and merge atomically only when validated. Large tables are changed safely because production is untouched until a clean merge, and any change is reversible by returning to an earlier commit.
How is Bauplan's branching different from LakeFS?
LakeFS branches and commits at the object-storage layer, versioning the files under your data. Bauplan branches at the execution layer over the whole dataset environment and ties the branch to the pipeline run that produces it. LakeFS versions storage; Bauplan versions execution, so a Bauplan commit is a validated change from a run, not only a snapshot of files. LakeFS does not execute pipelines, whereas execution is central to Bauplan's model.
Does Bauplan replace LakeFS?
For lakehouse pipelines, often yes. Bauplan provides the branching, commits, merges, and rollback teams adopt LakeFS for, and adds execution underneath, so the branch is the unit of execution rather than just a place files were written. Teams keep LakeFS when they need versioning over object storage beyond Iceberg tables, such as unstructured files or ML artifacts. For versioned, validated Iceberg pipelines, Bauplan covers it in one system.
