Several cloud database services now offer branches that are created in seconds from a snapshot, usually copy-on-write so that a branch shares unchanged pages with its parent. Developers use them to test a migration, run a feature against production-shaped data, or give each pull request its own database.
A branch solves isolation. Two people can change the same schema without stepping on each other, and a bad migration is thrown away with the branch. What a branch does not record is what was done to the data inside it, and why.
How is database branching different from data versioning?
- A branch is a working copy made for change. A version, as in data versioning, is a named state you can return to and compare against.
- Branching lives in the database engine. Versioning can sit at the dataset, file, or project level, independent of where the data is stored.
- For AI work the question is not only “which copy” but “which preparation steps and evaluation conditions produced this result”, and a branch on its own does not answer it.
Where does database branching break in AI work?
A team branches the warehouse, prepares a training set on the branch, trains a model, and reports a strong result. A month later the branch is gone, the main database has moved on, and nobody can say which rows were dropped, which codes were mapped, or which evaluation split was used. The result exists; the path to it does not.
The fix is to keep the preparation itself as the record, not only the copy. In Syntitan the original Dataset stays untouched, each use case starts from a copy as project Version 1, and preparation results are recorded as new Versions. Execution Trace, which will attach evaluation conditions and run results to those Versions, is in development. A branch gives a place to work; the Version gives a record that a second run or an audit can start from.
Model migration: freeze the data version shows the same discipline applied to a model switch, and data lineage covers how the path between tables is recorded.