Git4Data: Database-Native Version Control for AI Agents
Hongshen Gou, Zuyu Zhang, Yuze Sun, Peng Xu, Feng Tian, Long Wang, Jianguo Wang
cs.DB · cs.AI
Quick verdict
Claims Git-style SQL branching in MatrixOne beats DoltDB by up to 18.5x; sound design, plausible results, but thin baselines and no statistical rigor.
Summary
Git4Data adds Git-style version control to the MatrixOne cloud-native OLTP database: tables become versioned objects, and snapshot/tag, branch (clone from a snapshot), row-level diff, and three-way merge with explicit FAIL/SKIP/ACCEPT conflict policies are exposed as SQL extensions, so agents and engineers version data through ordinary SQL. The design rests on three storage properties — append-only immutable objects, deletion tombstones, and MVCC — so cloning copies only metadata and diff/merge scan just the object deltas added since two versions diverged, with primary keys supplying row identity (a multiset/rowid fallback applies without one). Reported results: cloning a 100 GB TPC-H lineitem table takes 0.20 s and 314 KB of metadata versus 114.6 s and 34 GB for an INSERT-based copy; built-in diff/merge beat SQL-equivalent formulations by up to two orders of magnitude (PK diff 3.27 s vs 431.50 s at the 1M-row update setting); and on BranchBench agentic workloads at scale factor 100 Git4Data runs 8.4x-18.5x faster than DoltDB while sustaining 1,000 concurrent branching agents (400 s vs DoltDB exceeding two hours). At SF1,000 scaling stays sublinear except for the whole-table failure_repro workflow (13.5x). Limitations include row-granularity conflict resolution, no schema evolution, weaker and non-monotonic no-primary-key timings, and a single-machine evaluation without stated run counts or variance.
Review complete
Assessment at a glance
0
risk flags identified
● high 0
● medium 0
● low 0
4 strengths · 5 weaknesses · 5 author questions
AI text signal = Binoculars zero-shot detector score over 20 sampled passages (Fast-DetectGPT co-reported) — absence does not prove human authorship, and a flag does not imply misconduct.
Levels reflect verification complexity — not a quality score. Evolve never rates your paper.
Key claims under review
- Git-style version control (snapshot/tag, branch, row-level diff, three-way merge with FAIL/SKIP/ACCEPT policies) can be exposed as SQL extensions over an append-only, MVCC-based OLTP storage engine.
- Metadata-only cloning and delta-based diff/merge make version-control cost proportional to change size: a 100 GB lineitem table clones in 0.20 s using 314 KB of metadata (Table 1).
- Built-in diff and merge outperform equivalent SQL formulations by orders of magnitude (PK diff 3.27 s vs 431.50 s at the 1M-update setting, Table 2).
- On BranchBench SF100 workloads, Git4Data runs 8.4x-18.5x faster than DoltDB end-to-end and sustains 1,000 concurrent branching agents (400 s vs DoltDB exceeding two hours, §4.2).
- Scaling to SF1,000 preserves sublinear cost for change-bound workflows, while whole-table workflows (failure_repro, 13.5x) track data size (Table 5).
Strengths
Cost model matches the mechanism, and is measured
Clone/diff/merge costs are mechanistically explained (§3.3-3.5) and measured: metadata-only clone of 100 GB lineitem in 0.20 s / 314 KB vs 114.6 s / 34 GB for INSERT-based copy (Table 1); diff reads only object deltas since divergence.
Relational semantics yield cleaner merging than Git-style text diffing
Primary keys collapse per-key operations into one logical delete/insert/update (§3.4); Listing 2 gives an exact SQL formulation of diff semantics; compaction-induced row relocation is treated as a non-conflict (§3.5), avoiding false conflicts from storage reorganization.
Large end-to-end deltas including concurrency headroom
Candid open-problems section
Weaknesses
Statistical reporting absent
Baseline coverage thin
NoPK timings are non-monotonic and unexplained
Internal inconsistency between Tables 4 and 5
Agent harness unspecified and generality overclaimed
Full Review Report
$1.99 · one-timeUnlock the complete preliminary analysis Evolve produced for this paper.
Report preview
Scope & Claims
Git4Data (MatrixOrigin + Purdue) argues that fleets of LLM agents exploring candidate states of relational data in parallel need first-class version-control primitives inside the database, and delivers them as SQL extensions in MatrixOne: CREATE SNAPSHOT, clone-from-snapshot branching (DATA BRANCH CREATE TABLE ... FROM T{snapshot=...}), DATA BRANCH DIFF, and three-way DATA BRANCH MERGE with WHEN CONFLICT FAIL|SKIP|ACCEPT (§2). The central claims are (i) cost proportional to change size rather than table size, enabled by append-only objects, deletion tombstones, and MVCC (§3.1); (ii) measured orders-of-magnitude wins over hand-written SQL equivalents (Tables 1-3); and (iii) 8.4x-18.5x end-to-end speedups over DoltDB on BranchBench at SF100, with 1,000-agent concurrency headroom (Table 4, §4.2). The abstract also claims applicability to 'any OLTP database,' which §3.1's three storage prerequisites substantially qualify.
The remaining sections cover Methodology Assessment, Statistical Evidence, Results & Reproducibility, Limitations & Risks, and Verdict & Recommendations.
- All 4 strengths & 5 weaknesses, analyzed in detail
- 0 risk flags with severity, section & reviewer questions
- Methods & statistical evidence assessment
- 5 questions a peer reviewer would ask
- Full six-dimension evaluation report & recommendations
One-time purchase · this paper only
One-time purchase, this paper only. AI-generated preliminary analysis — not peer review.
Frequently asked questions
What is Git4Data?
A version-control layer built into the MatrixOne database that exposes Git-style operations — snapshots/tags, table branching, row-level diff, and three-way merge with explicit conflict policies — as SQL statements, so tables can be versioned, compared, and merged without leaving SQL.
How much faster is Git4Data than DoltDB?
On the BranchBench agentic branching workloads at scale factor 100 (~47M rows), the paper reports end-to-end runtimes 8.4x to 18.5x faster than DoltDB; in a 1,000-concurrent-agent simulation Git4Data finished in 400 s while DoltDB did not finish within two hours.
How can cloning a 100 GB table take 0.2 seconds?
Because the clone copies only the metadata directory that points to immutable storage objects, not the data itself (314 KB of metadata in the paper's measurement); the branch then evolves independently while sharing the base data.
What are Git4Data's main limitations?
Conflicts are resolved only at row granularity (two edits to different columns of the same row still conflict), schemas cannot evolve across branches, no-primary-key tables diff/merge more slowly and erratically, and the evaluation is single-machine with no reported repetition counts or variance.
About this review
This is an AI-generated preliminary review by Evolve.Pub, produced from the openly available text of the paper. It is not peer review and does not represent the authors' views. The canonical record of the paper is at the publisher link above.
- The closing sentence of §6 ('...to learn how far these lessons.') appears to end mid-phrase just before the References; the extraction carries a terminal period there, so this may be as-published rather than truncation.
- PDF extraction fuses the arXiv stamp into a body line ('...0.2 s andarXiv:2609.02106v1 [cs.DB] 2 Sep 2026') and interleaves Figure 1's caption into the introduction; no numeric or table content is affected.
Go deeper on this paper
Wrote a paper? Stress-test it before reviewers do.
Upload your manuscript for the same structured scrutiny — reasoning, statistics, evidence, figures, and reproducibility.