Paper deep dive
Git4Data: Database-Native Version Control for AI Agents
Hongshen Gou, Zuyu Zhang, Yuze Sun, Peng Xu, Feng Tian, Long Wang, Jianguo Wang
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 9/3/2026, 3:49:58 AM
Summary
The paper introduces Git4Data, a database-native version control layer for AI agents implemented in the MatrixOne relational database. It enables Git-style operations (snapshot, branch, diff, merge) via SQL extensions, leveraging immutable object storage and MVCC to ensure operation costs are proportional to data changes rather than total dataset size. Git4Data outperforms DoltDB by up to an order of magnitude on agentic branching workloads.
Entities (7)
Relation Signals (6)
Git4Data → exposes → SQL
confidence 95% · exposing Git-style operations ... through SQL extensions.
Git4Data → implements → MatrixOne
confidence 95% · Implemented in MatrixOne, a cloud-native relational database, Git4Data leverages...
Git4Data → evaluatedon → BranchBench
confidence 90% · On the BranchBench agentic branching workloads...
Git4Data → outperforms → DoltDB
confidence 90% · On the BranchBench agentic branching workloads, Git4Data outperforms DoltDB by up to an order of magnitude.
Git4Data → supports → LLM Agents
confidence 90% · Git4Data, a database-native version-control layer for agentic workflows.
Git4Data → uses → MVCC
confidence 90% · Git4Data leverages immutable object storage and MVCC...
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Large Language Model (LLM) agents increasingly explore many candidate states of relational data in parallel, each of which should remain isolated, reproducible, and auditable, preferably through the same SQL interface used for ordinary data work. Existing tools support this requirement only partially: source-code version control does not scale to large datasets, whereas relational databases manage large data efficiently but rarely expose native branching, comparison, and merging. We present Git4Data, a database-native version-control layer for agentic workflows. Git4Data treats a database as a repository and a table as a versioned object, exposing Git-style operations (snapshot/tag, branch, diff, and merge with explicit conflict-resolution policies) through SQL extensions. Implemented in MatrixOne, a cloud-native relational database, Git4Data leverages immutable object storage and MVCC to make the cost of these operations proportional to the size of the change rather than the size of the data. On the BranchBench agentic branching workloads, Git4Data outperforms DoltDB by up to an order of magnitude. Overall, we believe this work sheds light on how relational databases can better support AI agents through efficient versioning.
Tags
Links
- Source: https://arxiv.org/abs/2609.02106v1
- Canonical: https://arxiv.org/abs/2609.02106v1
Trouble viewing inline? Open PDF directly →
Full Text
37,988 characters extracted from source content.
Expand or collapse full text
printacmref=false Git4Data: Database-Native Version Control for AI Agents Hongshen Gou Zuyu Zhang Yuze Sun Peng Xu Feng Tian Long Wang Jianguo Wang§ Affiliation: Purdue University§ gouhongsheng; zuyuzhang; sunyuze; xupeng@matrixorigin.cn tianfeng; wanglong@matrixorigin.io csjgwang@purdue.edu§ Abstract. Large Language Model (LLM) agents increasingly explore many candidate states of relational data in parallel, each of which should remain isolated, reproducible, and auditable, preferably through the same SQL interface used for ordinary data work. Existing tools support this requirement only partially: source-code version control does not scale to large datasets, whereas relational databases manage large data efficiently but rarely expose native branching, comparison, and merging. We present Git4Data, a database-native version-control layer for agentic workflows. Git4Data treats a database as a repository and a table as a versioned object, exposing Git-style operations (snapshot/tag, branch, diff, and merge with explicit conflict-resolution policies) through SQL extensions. Implemented in MatrixOne, a cloud-native relational database, Git4Data leverages immutable object storage and MVCC to make the cost of these operations proportional to the size of the change rather than the size of the data. On the BranchBench agentic branching workloads, Git4Data outperforms DoltDB by up to an order of magnitude. Overall, we believe this work sheds light on how relational databases can better support AI agents through efficient versioning. 1. Introduction Large Language Model (LLM) agents are beginning to act as data engineers Fernandez et al. (2023): they read relational data, propose transformations Narayan et al. (2022), evaluate SQL Li et al. (2024), and iterate. Unlike a human engineer working on one snapshot at a time, a fleet of agents explores many candidate states in parallel Liu et al. (2026); Ang et al. (2026), and each agent must be isolated, reproducible, and auditable. An agent must fork data before speculative updates, inspect row-level diffs, merge only validated changes, and roll back failed paths without copying the base version. In other words, agentic workflows require data-version primitives as first-class, database-native operations rather than as external tools. raw tableS0S_0: messy B1B_1: rule-based normalize B2B_2: fuzzy entity dedup B3B_3: agentic semantic clean cross-branch agreement + quality row-level merge accepted deltas →Sr→ S_r Figure 1. Agentic data repair workflow with Git4Data Consider agentic data repair workflow in Figure 1. A raw snapshot S0S_0 contains duplicate entities, malformed fields, and inconsistent records. Rather than committing to one cleaning strategy up front, an agent branches S0S_0 and applies a different SQL repair to each candidate: categorical normalization, fuzzy entity deduplication, and context-dependent semantic fixes. Each evaluates the candidates with SQL queries and proxy quality signals, prunes poor branches, and compares promising ones through diffs. Because each strategy repairs a different subset of the records, no branch wins outright, and the goal is to selectively merge accepted row-level deltas into a repaired state SrS_r while preserving an audit trail of what was tried, accepted, and rejected. Software engineering already has mature support for these primitives, with Git Chacon and Straub (2014) as the de facto standard. However, data engineers do not have a comparable foundation. Applying a source-code version control system (VCS) to large datasets is prohibitively slow, because its diff and merge tools load and compare the entire dataset in memory, and it does not scale to billions of records stored in cloud object stores. Relational databases mutate data efficiently via transactions, but do not provide explicit version control. Multi-Version Concurrency Control (MVCC) retains row versions in a linear history, but does not allow tracing back at a specific version, let alone doing so at agent swarm scale. Database snapshots and Point-In-Time Recovery (PITR) capture named past versions, yet support only read and restore at a single timeline, but cannot hold two writable lines of work. Writable clones of tables or databases in Snowflake Dageville et al. (2016) and Supabase Supabase (2026) allow development and testing in parallel, and Neon Neon Team (2026) forks an entire Postgres instance at any point in its history through storage-level copy-on-write. But none of these systems can report the row-level differences between two branches, whether both branches modify the same rows, or merge validated changes into a new version. In other words, what is missing in databases is not the ability to capture or fork data changes, but the SQL-level operations to manipulate the resulting versions: comparison and conflict-aware reintegration. We propose Git4Data, a new abstraction that supplies exactly this missing layer. Git4Data treats a database as a repository and a table as a versioned object. By extending snapshot/tag, branch, row-level diff, and merge as SQL statements (Section 2), an engineer or an LLM agent could version data through the interface already used for data work, and changes spanning multiple tables publish in one transaction. Merge is three-way and conflict-aware rather than last-writer-win. Conflict resolution is currently at the row granularity, and richer semantic resolution is one of the research problems this abstraction opens (Section 6). We then implement an initial version of Git4Data in MatrixOne MatrixOrigin (2026), a cloud-native relational database. Our key observation is that a modern OLTP database already provides the mechanisms for the concept, where data resides in immutable, append-only objects governed by MVCC. A table version is just a lightweight metadata, and two versions differ only in the objects written since they diverged, letting diff and merge read only those deltas. The initial results are encouraging: cloning a 100 GB table takes 0.2 s and a few hundred kilobytes of metadata; diff and merge outperform their SQL equivalents by orders of magnitude. On BranchBench Ang et al. (2026) agentic branching workloads Git4Data runs up to an order of magnitude faster than DoltDB Dolt (2026) while sustaining 1,000 concurrently branching agents. This paper makes the following contributions: • We propose Git4Data, a database-native version-control abstraction that exposes branch, diff, and merge as SQL extensions, applicable to any OLTP database (Section 2). • We implement a Git4Data prototype in MatrixOne11 1 Git4Data is open source as part of MatrixOne at https://github.com/matrixorigin/matrixone., where metadata-only cloning and delta-based diff and merge keep the cost proportional to the changes (Section 3). • We evaluate the prototype on BranchBench, observing up to an order of magnitude speedup over DoltDB at 1,000 concurrent agents (Section 4). • We distill the lessons of building Git4Data and identify the open problems that we believe start a new line of research on in-database version control (Section 6). 2. Git4Data This section presents Git4Data, which derives much of its utility from a small, composable vocabulary in Git: record a version, branch from it, compare versions, and integrate selected changes. Git4Data brings this vocabulary to relational data by mapping each Git concept onto a database construct. The database serves as the data repository where each table is a versioned object: • a snapshot names an immutable table state, the analogue of a commit or tag; • a branch is a new table cloned from a snapshot, after which the two evolve independently; • diff reports the rows on which two versions disagree; • merge folds accepted changes from one branch into another under an explicit conflict policy. Two decisions shape how the vocabulary transfers. First, each operation is a SQL statement executed inside the database, so versioning inherits the transactions, authentication, and access control that data engineers already rely on, and both engineers and agents version data through the same interface they use for ordinary data work. Second, versions are compared as relational content rather than as byte streams, where Git4Data treats a table version as an unordered multiset of rows, with the primary key, when present, supplying a stable row identity across versions, so the semantics are independent of physical layout and row order. Nothing in this vocabulary is tied to one engine: the operations are defined at the SQL level, and any OLTP database could achieve them with the same semantics. Their cost, however, depends on the storage design. If the storage engine keeps table data immutable, a snapshot is merely metadata: branching does not occur data copies, and two versions differ only in what were written after they diverged, so each operation costs in proportion to the change rather than to the whole table size. 2.1. Operations We present the operations in their typical workflow order, as a single table T takes a snapshot or a branch, compares, and reconciles. Listing 1 depicts the running workflow used throughout the paper, where T and its clone TClone diverge from a common base snapshot sn1, and eventually merge into sn4. Listing 1: Running branch-and-merge workflow ⬇ T: --> sn1 --> sn2 ------> sn4 --> \ / TClone: \---> sn3 --/ ------------- now ---------> time Snapshot. Every version-control workflow requires the ability to name a past state. In Git4Data, a snapshot freezes a table at an instant, and plays the role of a Git commit. The most lightweight form is implicit: a multi-version storage engine already retains point-in-time history for a recent window (i.e., 24 hours), so a recent state can be queried directly by timestamp, SELECT * FROM Ttimestamp=’2026-08-01 12:34:56’; without requiring the user to declare the state in advance. When a state should be retained explicitly, the user promotes it to a named snapshot, the analogue of a Git tag, with CREATE SNAPSHOT sn1 FOR TABLE T; We write Tsn1T_sn1 for the resulting snapshot of T. Git4Data also supports database-level snapshots; for clarity we develop the operations at the granularity of a single table. Branch. A snapshot becomes a starting point for new work the moment it is cloned into a fresh table: DATA BRANCH CREATE TABLE TClone FROM Tsnapshot=’sn1’; The clone TClone inherits the schema and data of Tsn1T_sn1, but from that point the two tables evolve independently: inserts, deletes, and updates on T and TClone no longer affect one another. This is precisely the isolation an agent needs to explore a speculative change without endangering production state. In the running workflow, T then advances to snapshot sn2 while TClone advances to sn3. Diff. Once two lines of work diverge, the natural question is how they differ. DATA BRANCH DIFF compares between two snapshots: DATA BRANCH DIFF Tsnapshot=’sn2’ AGAINST TClonesnapshot=’sn3’; Conceptually, the operation treats each snapshot as an unordered multiset of records and reports the rows where the two multisets disagree. The semantics are captured precisely by the query in Listing 2: each row contributes a signed count, and the rows whose counts do not cancel are exactly those that differ. Listing 2: Query equivalent to DATA BRANCH DIFF ⬇ WITH UnionT AS ( SELECT -1 AS cnt, a, b, c FROM Tsnapshot=’sn2’ UNION ALL SELECT 1 AS cnt, a, b, c FROM TClonesnapshot=’sn3’ ) SELECT SUM(cnt) AS diffCnt, a, b, c FROM UnionT GROUP BY a, b, c HAVING SUM(cnt) <> 0; Merge. This operation folds accepted changes back into the target table. Branches from a fleet of agents typically succeed on different subsets of the data, so no single branch can simply be promoted to replace the original. Meanwhile the live table keeps receiving writes, as shown in Listing 1, T advances to sn2 while TClone is being explored, so swapping T for a branch would silently discard that concurrent progress, and re-applying the branch’s changes through hand-written SQL reintroduces a slow, error-prone path. A merge reconciles two histories instead: DATA BRANCH MERGE TClonesnapshot=’sn3’ INTO T [WHEN CONFLICT FAIL|SKIP|ACCEPT]; The source may be any snapshot, whereas the target must be the live table version. Rather than overwriting one side with the other, Git4Data infers the common base revision Tsn1T_sn1 and performs a three-way merge, so that non-overlapping changes from both branches survive. What happens when the branches do overlap is governed by the WHEN CONFLICT clause, which offers three policies: FAIL aborts the merge, SKIP keeps the target’s version of a conflicting row, and ACCEPT keeps the source’s. Conflict Resolution. Whether two changes actually collide depends on how rows are identified, and here the presence of a primary key is decisive. When the table declares one, Git4Data compares the corresponding row across the base, target, and source snapshots and flags a genuine conflict only when both branches independently modify the same key, including the case in which two branches insert the same new key. If only one branch touched the row, or if both applied identical changes, the outcome is unambiguous and Git4Data resolves it automatically. Without a primary key, no stable identity ties a row in one branch to a row in another, so Git4Data falls back to multiset reasoning. Inserted rows are grouped by their full values, while deleted rows are tracked through the storage engine’s physical row identifiers. A conflict is suspected only when the same changed row or row value appears in both branch deltas and cannot be canceled as an identical change; changes confined to one side are applied automatically, and anything that remains is resolved under SKIP, ACCEPT, or FAIL. 3. Design and Implementation In this section, we present the design and implementation of Git4Data. We first identify the capabilities that an OLTP database must provide to support it efficiently, then describe MatrixOne, a cloud-native database, and finally explain how each operation is implemented. 3.1. Key Requirements Git4Data operations rely on three requirements, which we state independently of any particular storage engine. Append-only data. The storage engine never modifies data in place: inserts and updates append new, immutable data units. A snapshot only needs to record the table version to which the units belong, branching copies the metadata, and the difference between two versions is confined to the units appended after they diverged. Deletion marks. Deleted tuples must be recorded explicitly, rather than applied in place. Deletion marks allow diff to report deleted rows without scanning the full table, while merge can distinguish a row deleted on one branch from a row deleted on both. Multi-Version Concurrency Control. Version-control operations must execute as transactions, so that a merge publishes its accepted changes atomically and concurrent branches never observe a partial state. MVCC additionally gives every committed state a well-defined point-in-time identity, the implicit timestamp of snapshot name. Many modern OLTP databases built on log-structured, multi-version storage engine satisfy all three requirements. We implement Git4Data in MatrixOne MatrixOrigin (2026), one such system described below. 3.2. MatrixOne MatrixOne is a cloud-native HTAP database organized around three principal node types (Figure 2). LogService nodes form a Raft Ongaro et al. (2014) group and store the Write-Ahead Log (WAL). A TransactionNode (TN) determines transaction commits, serializes committed logs, and streams WAL records to subscribed ComputeNodes (CNs). CNs execute SQL queries and scale out independently. ComputeNode0ComputeNode1ComputeNode2TrxNodeLogService2LogService1LogService3 RaftCloud Object Storage Figure 2. MatrixOne architecture MatrixOne Database Architecture MatrixOne stores table data in cloud object storage. Objects are immutable, hold column-store row groups Stonebraker et al. (2005), and form an LSM tree O’Neil et al. (1996) ordered by the primary key, or by clustering keys together with a uniquifier. Deletes are represented by tombstone objects that record the key and physical row id of the deleted rows. Metadata consists of a directory of data objects and tombstone objects. MatrixOne employs MVCC. Transactions execute on CNs and maintain private workspaces. Large transaction workspaces are written directly to cloud object storage, and the commit record sent to TN carries the corresponding object metadata. Small writes may instead accumulate in a TN-managed in-memory object; each row carries a transaction timestamp, and the object remains append-only until flushed to cloud. Committed WAL records are streamed to subscribed CNs to keep table state and local object caches fresh. A table snapshot is the metadata directory for all objects that belong to the table at a given version, including both flushed in-memory objects and remote objects. Reading a timestamp snapshot traverses this directory and applies MVCC timestamp filters. Creating a named snapshot first flushes in-memory objects and then records the metadata directory under the snapshot name. As in other log-structured storage systems O’Neil et al. (1996); Rosenblum et al. (1992), MatrixOne relies on background compaction and garbage collection. Garbage collection is snapshot-aware: objects referenced by named snapshots are retained, which allows Git4Data to maintain branches and tags without copying table data. 3.3. Implementation We now describe how Git4Data implements clone, diff, and merge over MatrixOne snapshots. Cloning a table from a snapshot is pure metadata: MatrixOne copies the directory structure of the snapshot’s object metadata into the new table. Diff and merge operate on object deltas. Consider tables T and TClone in Listing 1: after TClone is created, both may be modified independently, advancing to distinct snapshots sn2 and sn3. We write Δsn2 _sn2 for the objects in Tsn2T_sn2 but not in the common base revision Tsn1T_sn1, and Δsn3 _sn3 analogously for TClonesn3TClone_sn3. A delta contains the objects added by data modifications, with deletions represented as tombstone records. It may also contain objects retained only in Tsn1T_sn1 as a result of compaction or garbage collection. 3.4. Diff To compute DATA BRANCH DIFF between Tsn2T_sn2 and TClonesn3TClone_sn3, MatrixOne reads only Δsn2 _sn2 and Δsn3 _sn3. With a primary key, all operations on one key within a delta collapse into a single logical operation: a delete, an insert, or an update represented as a delete followed by an insert. Deletions are always applied to a row in Tsn1T_sn1. This scan mirrors an ordinary LSM-tree scan with tombstones, except that it emits deletions rather than masking deleted rows, assigning a minus sign to each deletion and a plus sign to each insert. It differs from the SQL diff of Listing 2 in two ways: its signs express Tsn2T_sn2 versus Tsn1T_sn1 (not versus TClonesn3TClone_sn3), and deleted rows initially emit only tombstones whose non-key columns are null. MatrixOne joins with Tsn1T_sn1 to recover the original values only when they are required. MatrixOne then aggregates the two deltas: changes are identical, and cancel, when they delete the same row of Tsn1T_sn1 or insert rows equal in all columns. The final output flips the sign of rows from Δsn2 _sn2 and, for each remaining tombstone, joins with Tsn1T_sn1 to recover its non-key columns. Without a primary key, the same procedure applies, but rows are matched by full value and by physical rowid: insertions with identical values and deletions with the same rowid cancel, and deleted rows are recovered by rowid lookup. 3.5. Merge A three-way merge from TClone into T runs the same scan and diff aggregation over Δsn2 _sn2 and Δsn3 _sn3 (Section 3.4); the plus and minus signs indicate whether a row was inserted into a snapshot or deleted from the base. With a primary key, a conflict is genuine when the key appears in both deltas and spurious when it appears on only one side; a row relocated by compaction (same values, new position) is recognized as a non-conflict, so a storage reorganization never masks a valid update from the other branch. This is the only case requiring a full read of the deleted base row, and such lookups are rare. Without a primary key, rows are matched as a multiset of full values: identical full-row values from the two deltas cancel one occurrence at a time, preserving duplicate multiplicity, so equal rows on both sides are cancellations rather than conflicts, consistent with the row-multiset semantics of Section 2. Users need not name the common base revision. MatrixOne tracks snapshot and clone lineage and usually infers it, implementing a two-way merge as a three-way merge with an implicit base. When the base cannot be determined or no longer exists (for example, the original table and all of its snapshots were deleted), the merge uses an empty base; even then, two clones of a common ancestor share many objects, so the diff aggregation still beats the SQL query of Listing 2 by skipping the shared objects. Snapshots also protect history: MatrixOne never compacts or garbage-collects objects referenced by a named snapshot. Compaction or GC scheduled between sn1 and a later snapshot rewrites valid rows into new objects, which can move rows without changing their values; as above, the diff aggregation treats such relocated rows as unchanged and avoids false conflicts. Because users typically branch from well-organized snapshots, compaction within the common base revision is rare. 4. Experimental Evaluation This section evaluates Git4Data on a microbenchmark and compares against DoltDB Dolt (2026) on BranchBench Ang et al. (2026). Our experiments were conducted on a bare-metal server running CentOS, equipped with an Intel Xeon Silver CPU (2.4 GHz, 64 cores), 256 GB of main memory, and local SSDs, with MatrixOne deployed on Kubernetes. 4.1. Version-Control Operations We first microbenchmark the individual version-control operations on both primary-key (PK) and no-primary-key (NoPK) settings. We compare Git4Data against equivalent hand-written SQL in MatrixOne using the TPC-H Transaction Processing Performance Council (2022) lineitem table at Scale Factor 100. Clone. We compare the metadata-only clone against materializing a full copy of the lineitem table: INSERT INTO T SELECT * FROM lineitem; Table 1 reports the cost of clone versus insert. Cloning from a snapshot copies only metadata, whereas the INSERT writes an entirely new table, incurring 34 GB of additional storage. Table 1. Git4Data Clone vs. Insert on 100 GB lineitem table. Operation Time (s) Space Clone, PK 0.20 314 KB Clone, NoPK 0.17 294 KB Insert, PK 114.6 34 GB Insert, NoPK 119.3 34 GB Diff and merge. We apply four update sets on the lineitem clones: C1, C2, C3, and C4 update 1,000, 10,000, 100,000, and 1,000,000 random rows, respectively, and then differ against the original table and merge the changes back using ACCEPT. The SQL diff shows in Listing 2, while the SQL merge materializes that diff, deletes the rows with negative counts, and inserts the rows with positive counts. Table 2. Single-branch diff, Git4Data vs. SQL. Operation C1 C2 C3 C4 Git4Data Diff, PK 0.19 0.38 1.73 3.27 Git4Data Diff, NoPK 0.85 22.50 9.04 60.19 SQL Diff, PK 316.16 418.19 428.78 431.50 SQL Diff, NoPK 378.19 396.61 394.13 371.74 The built-in diff is substantially faster than the SQL diff (Table 2), because it scans only the changed objects rather than the entire tables. The advantage is larger with primary keys, since row ids let MatrixOne collapse multiple operations on the same key before aggregation. In the no-primary-key case, deleted rows may require additional tuple lookups, so the benefit is smaller and varies with the different number of lookups. Table 3. Single-branch merge, Git4Data vs. SQL. Operation C1 C2 C3 C4 Git4Data Merge, PK 0.35 0.97 7.95 16.13 Git4Data Merge, NoPK 0.88 22.70 12.09 68.75 SQL Merge, PK 321.52 412.89 442.68 471.16 SQL Merge, NoPK 393.95 405.35 401.59 403.18 The built-in merge is likewise substantially faster than the SQL alternative (Table 3). Primary keys provide stable row identity, allowing the scan and diff aggregation to group multiple operations on the same key into a single logical operation. The same advantage holds in collaborative settings. For four engineers who fork lineitem and merge mostly non-overlapping updates, with two branches conflicting on a 10% PK overlap resolved by ACCEPT, the built-in diff and merge remain orders of magnitude faster than the SQL counterparts, even for one million updates. 4.2. BranchBench We now turn to end-to-end agentic workloads, studying how Git4Data behaves as agent count and data size grow. BranchBench Ang et al. (2026) defines branch lifecycle, branch-local SQL, cross-branch comparison, and pruning workloads for agentic database branching. We run four end-to-end workflows, software development, failure reproduction, data cleaning, and Monte Carlo tree search (MCTS), at scale factor 100 (approximately 47 million rows). Each is driven by five concurrent agents over 20 steps, with each agent forking the database, issuing branch-local SQL, and merging or discarding its branch. We compare Git4Data against DoltDB Dolt (2026), a MySQL-compatible database with built-in Git-style branching, reporting end-to-end wall-clock time for a cold run and the average over warm runs in Table 4. A fifth workflow, simulation, stresses branch concurrency with 1,000 agents and is examined separately below. Table 4. BranchBench at Scale Factor 100 runtime (s) Git4Data DoltDB Workflow Cold Warm Cold Warm Speedup software_dev 138.9 122.1 1938.8 1925.6 15.8× failure_repro 207.6 198.9 1545.5 1677.3 8.4× data_cleaning 62.6 58.6 1075.2 1084.2 18.5× mcts 36.0 39.8 410.4 410.2 10.3× Across all four workflows, Git4Data is up to 18.5×18.5× faster than DoltDB, which materializes and compares table contents, so each branch operation scales with table size. Git4Data’s snapshot-and-delta operations scale with the size of the change, and exhibit low runtime variance under 3.5 s. Scaling number of agents. The simulation workflow stresses branch concurrency directly, launching 1,000 concurrent agents, each of which forks the database and performs a branch-local step. At scale factor 100, Git4Data completes in 400 s, whileas DoltDB fails to finish within two hours. This confirms that metadata-level branching keeps per-fork cost negligible even at high agent counts. The remaining cost is dominated not by branching itself but the shared compute and I/O consumed when thousands of branch-local executions run concurrently, which we identify as the primary bottleneck as the number of agents grows. Table 5. Git4Data BranchBench scaling experiments. Workflow SF100 SF1,000 Factor software_dev 127.5 366.3 2.9× data_cleaning 99.3 322.5 3.2× failure_repro 199.0 2685.7 13.5× Scaling data size. To see how Git4Data performs as data grow, we rerun the BranchBench workflows at scale factor 1,000 (Table 5). The branch-local workflows scale sublinearly: software_dev and data_cleaning slow by at most 3.2×3.2×, and mcts stays essentially flat (under 40 s warm), even though the data grows by 10×10×. Their cost is set by the bounded per-step deltas each agent writes, not by the size of the underlying table. The only exception is failure_repro, which grows about 13×13×: its repairs scan and rewrite the entire table, so its cost tracks data size rather than change size. The 1,000-agent simulation finishes in 600 s at SF1,000, comparable to 400 s at SF100, which confirms that per-fork cost stays metadata-bound as data grows. Overall, Git4Data’s delta-oriented design preserves its efficiency at an order-of-magnitude larger scale, except where a workflow inherently touches the whole table. 5. Related Work This section reviews prior work in five dimensions: version control, storage snapshots, data-lake versioning, database cloning and branching, and agentic data workloads. Version control systems trace back to early software-engineering practice Rochkind (1975). Distributed systems such as Git Chacon and Straub (2014) subsequently became the standard for source-code collaboration. Support for large data is typically retrofitted as an extension: Git LFS GitHub (2026) provides large-file storage and retrieval, and DVC Iterative (2026) versions datasets and models through Git-tracked pointer files, but neither offers record-level diff or conflict resolution. Closer to Git4Data in spirit are data-lake versioning systems. Apache Iceberg Apache Software Foundation (2026) maintains per-table snapshot lineage with branch and tag references, Nessie Project Nessie (2026) versions an entire Iceberg catalog with Git-like branches and merges, and lakeFS Treeverse (2026) provides zero-copy branches, commits, and three-way merge over an object-store namespace. These systems share Git4Data’s metadata-only branching philosophy: a lakeFS commit, for example, is an immutable manifest whose merge copies unchanged ranges wholesale. They version file manifests, but the unit of diff identity is an object or a table rather than a row: two branches that update disjoint rows of the same table still collide, and a conflict is resolved by keeping one side’s file. Git4Data applies the same snapshot-and-delta discipline inside the OLTP database, where primary keys give rows a unique identity and merge reconciles at record granularity. Many database systems support snapshots, restore, and Point-In-Time Recovery (PITR), but creating a writable branch exposes the limits of engines that couple compute with in-place-update storage. PostgreSQL 18 can delegate the database copy to file-system cloning (reflink) PostgreSQL Global Development Group (2026), but requires that no other active session access the source database for the duration of the copy, making it effectively an offline operation. Disaggregated, versioned storage removes the copy altogether: Snowflake Dageville et al. (2016) and Supabase Supabase (2026) offer zero-copy clones for development and testing, and Neon Neon Team (2026) branches online, at no cost to the parent, by recording a fork point in its LSN-indexed page history. Neon’s branches, however, are coarse-grained: a single table cannot branch alone. Moreover, none of these systems can compare two branches at the row level or merge one into another, so divergence is one-way. DoltDB Dolt (2026) brings Git-style branch, diff, and merge operations to a MySQL-compatible SQL database. Git4Data likewise exposes branch-oriented data workflows, but realizes them as database-native snapshot operations at table granularity in MatrixOne, with an emphasis on efficient diff and merge over large table forks. Agentic workloads provide a further motivation for branchable data management, as they frequently require parallel exploration of a hypothetical data space. Recent work on agent-first data systems characterizes this pattern as agentic speculation Liu et al. (2026): agents may fork a database state, run speculative updates, and roll back branches. Each branch furnishes an isolated state where an agent can apply speculative mutations, assess their effects, and then discard, compare, or merge the resulting changes. BranchBench Ang et al. (2026) is a recent benchmark for agentic database branching that models branch lifecycle operations, branch-local SQL, cross-branch comparison, and pruning as first-class workload dimensions (Section 4). 6. Lessons and Future Work We share three lessons learned from building Git4Data that we believe extend beyond MatrixOne, and finally highlight important open problems. Data version control is a storage property. Our implementation shows that data version control can be built on top of an existing transactional storage engine. An engine that already provides the three capabilities of Section 3.1, append-only data, deletion marks, and transactions, contains the necessary mechanisms: Git4Data is a thin interpretation layer over them and required no modification to the storage layer itself. We hope this work opens a line of research on data version management inside databases. Relational semantics simplify data versioning. While Git matches ordered lines of text heuristically, a relational engine obtains cleaner semantics for free. Data reconciliation based on primary key index outperforms the traditional value-based matching by more than an order of magnitude. But diff and merge assume compatible schemas, so schema evolution on long-lived branches remains open. New challenges surface in scaling the agent swarm. Once forking is a metadata operation and merges commit atomically, branch creation no longer constrains agent concurrency, and the dominant cost becomes the shared computation and I/O of concurrently executing branch-local workloads, shifting the open problem from storage efficiency to resource governance. Future directions. The bottleneck shift defines the first direction: resource governance for agent fleets. Thousands of speculative branches compete for shared compute and I/O, most will be discarded, yet the engine treats them as equal tenants; scheduling, admission control, and per-branch quotas that reflect an agent’s progress are open problems. Second, richer merge semantics. Resolution is currently row-level, so two branches editing different columns of the same row still conflict; cell-level resolution is the natural next step, but the harder problem is semantic, since row-disjoint changes can jointly violate constraints that neither branch violates alone, and conflict policies beyond SKIP and ACCEPT, including an agent that reviews DATA BRANCH DIFF output and acts as the merge driver, are unexplored. Third, schema evolution: diff and merge require compatible schemas, yet schema changes are common in practice, so schema must eventually be versioned together with data. Fourth, retention: named snapshots pin immutable objects, so sustained branching accumulates history, and balancing auditability against storage growth and compaction effectiveness requires explicit policy. Finally, we plan to validate Git4Data on production agentic workloads to learn how far these lessons. References Ang et al. (2026) Elaine Ang et al. 2026. BranchBench: An Extensible Benchmark for Agentic Database Branching. In Supporting Our AI Overlords (SAO) Workshop at the ACM Conference on AI and Agentic Systems (CAIS’26) (San Jose, CA). USA. Apache Software Foundation (2026) Apache Software Foundation. 2026. Apache Iceberg. https://iceberg.apache.org. Chacon and Straub (2014) Scott Chacon and Ben Straub. 2014. Pro Git (2 ed.). Apress, Berkeley, CA, USA. Dageville et al. (2016) Benoit Dageville et al. 2016. The Snowflake Elastic Data Warehouse. In Proceedings of the 2016 International Conference on Management of Data (SIGMOD ’16). Dolt (2026) Dolt. 2026. Version-Controlled SQL Database. https://github.com/dolthub/dolt. Fernandez et al. (2023) Raul Castro Fernandez et al. 2023. How Large Language Models Will Disrupt Data Management. Proc. VLDB Endow. 16, 11 (July 2023), 3302–3309. GitHub (2026) GitHub. 2026. Git Large File Storage (git-lfs). https://github.com/git-lfs/git-lfs. Iterative (2026) Iterative. 2026. DVC: Data Version Control. https://dvc.org. Li et al. (2024) Boyan Li et al. 2024. The Dawn of Natural Language to SQL: Are We Fully Ready? Proc. VLDB Endow. 17, 11 (July 2024), 3318–3331. doi:10.14778/3681954.3682003 Liu et al. (2026) Shu Liu et al. 2026. Supporting Our AI Overlords: Redesigning Data Systems to be Agent-First. the 16th Conference on Innovative Data Systems Research. MatrixOrigin (2026) MatrixOrigin. 2026. MatrixOne. https://github.com/matrixorigin/matrixone. Narayan et al. (2022) Avanika Narayan et al. 2022. Can Foundation Models Wrangle Your Data? Proc. VLDB Endow. 16, 4 (Dec. 2022), 738–746. doi:10.14778/3574245.3574258 Neon Team (2026) Neon Team. 2026. Neon Branching - Branch your data the same way you branch your code. https://neon.com/docs/introduction/branching. O’Neil et al. (1996) Patrick O’Neil et al. 1996. The Log-Structured Merge-Tree (LSM-Tree). Acta Informatica 33, 4 (1996), 351–385. Ongaro et al. (2014) Diego Ongaro et al. 2014. In search of an understandable consensus algorithm. In the 2014 USENIX Conference on Annual Technical Conference (USENIX ATC’14). PostgreSQL Global Development Group (2026) PostgreSQL Global Development Group. 2026. PostgreSQL: CREATE DATABASE. https://w.postgresql.org/docs/current/sql-createdatabase.html. Project Nessie (2026) Project Nessie. 2026. Project Nessie: Transactional Catalog for Data Lakes with Git-like Semantics. https://projectnessie.org. Rochkind (1975) Marc J. Rochkind. 1975. The Source Code Control System. IEEE Transactions on Software Engineering SE-1, 4 (1975), 364–370. Rosenblum et al. (1992) Mendel Rosenblum et al. 1992. The Design and Implementation of a Log-Structured File System. ACM Transactions on Computer Systems 10, 1 (1992). Stonebraker et al. (2005) Mike Stonebraker et al. 2005. C-Store: A Column-oriented DBMS. In Proceedings of the 31st International Conference on Very Large Data Bases (VLDB). Supabase (2026) Supabase. 2026. Supabase. https://supabase.com/docs/guides/database/overview. Transaction Processing Performance Council (2022) Transaction Processing Performance Council. 2022. TPC Benchmark H Standard Specification. https://w.tpc.org/tpch. Treeverse (2026) Treeverse. 2026. lakeFS: Data Version Control for Data Lakes. https://lakefs.io.