--- title: What is Git4Data? | daily.dev description: A detailed technical critique examines MatrixOrigin's Git4Data paper, which proposes adding Git-style version control to existing SQL databases built on LSM... canonical: https://daily.dev/posts/what-is-git4data--smb6mm89e twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: What is Git4Data? | daily.dev og:description: A detailed technical critique examines MatrixOrigin's Git4Data paper, which proposes adding Git-style version control to existing SQL databases built on LSM... og:url: https://daily.dev/posts/what-is-git4data--smb6mm89e og:image: https://api.daily.dev/og/posts/SMb6MM89e.png og:image:alt: What is Git4Data? og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # What is Git4Data? **[DoltHub Blog](https://daily.dev/sources/dolthub-blog)** · 12 min read · 1 upvotes · 0 comments ## Summary A detailed technical critique examines MatrixOrigin's Git4Data paper, which proposes adding Git-style version control to existing SQL databases built on LSM trees, without a custom storage layer like Dolt uses. The author, from DoltHub, could not reproduce the paper's benchmark claiming 8x-18x speedups over Dolt because MatrixOne crashed during setup, but concludes the design is plausible and clever. The analysis argues Git4Data's approach works by avoiding compaction of data objects referenced by snapshots, which creates serious tradeoffs: unbounded data growth, inability to remove tombstoned rows, and full table scans when diffing tables without shared data objects or common history. The piece also corrects a claim in the paper about Dolt's diff performance, noting Dolt's merges scale with the number of non-overlapping modified ranges rather than table size, and argues Git4Data's benchmark (BranchBench) wouldn't surface these long-term performance issues since it simulates fresh databases rather than long commit histories. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What tradeoffs does Git4Data have compared to Dolt for database version control? Git4Data avoids compacting data objects referenced by named snapshots to preserve diffing efficiency, but this means tables can grow unbounded and tombstoned rows can never be removed from storage, since compaction is the only mechanism to physically delete them. Every new snapshot also forces a data flush, so query performance degrades as the number of snapshots in a table's history grows, unlike Dolt's bounded Prolly Tree structure. _Engineers weighing version-controlled database designs can track this kind of tradeoff analysis on daily.dev._ ### Why can't LSM-tree based databases achieve efficient diff and merge like Dolt's Prolly Trees? LSM-trees lack history independence, meaning two tables with identical data but different histories will not share the same underlying data objects unless one was explicitly branched from the other. This forces full table scans when diffing tables with no common history or when the same insert happens independently on two branches, since the database can't recognize the rows as identical without comparing object contents. _Developers comparing storage engines for branching databases can follow deep dives like this on daily.dev._ ### How does Dolt's merge performance scale compared to the size of the diff? Dolt merges scale with the number of non-overlapping modified ranges rather than the overall table size or the size of the change itself. If two branches modify distinct ranges of the primary key space, merging is O(logN) relative to table size regardless of how large the actual changes are, a result of Dolt's fast-merge implementation rather than materializing and comparing full table contents. _Teams benchmarking database merge performance can keep up with findings like this through daily.dev._ ## Similar posts on daily.dev - [Version Controlled SQL Database Dolt Releases 2.0 with Automatic Storage Cleanup and Compression](https://daily.dev/posts/version-controlled-sql-database-dolt-releases-2-0-with-automatic-storage-cleanup-and-compression-wfaha9aol) · InfoQ · 1 upvotes · 0 comments - [Data Versioning in Machine Learning and Data Lakes](https://daily.dev/posts/data-versioning-in-machine-learning-and-data-lakes-znyfovuze) · Medium · 0 upvotes · 0 comments - [What People Are Saying: Better Stack Edition](https://daily.dev/posts/what-people-are-saying-better-stack-edition-e20vhxeem) · DoltHub Blog · 0 upvotes · 0 comments - [What People Are Saying: LWN Edition](https://daily.dev/posts/what-people-are-saying-lwn-edition-rqozyipga) · DoltHub Blog · 0 upvotes · 0 comments - [Deep Learning — Managing Training Data: lakeFS for the Files, MatrixOne for the Metadata](https://daily.dev/posts/deep-learning-managing-training-data-lakefs-for-the-files-matrixone-for-the-metadata-jtdbn7nwp) · Medium · 1 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#version-control](https://daily.dev/tags/version-control) [View this post on daily.dev](https://daily.dev/posts/what-is-git4data--smb6mm89e) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"What is Git4Data?","url":"https://daily.dev/posts/what-is-git4data--smb6mm89e","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/what-is-git4data--smb6mm89e"},"datePublished":"2026-10-01T18:41:25.418Z","dateModified":"2026-10-01T18:52:18.163Z","description":"A detailed technical critique examines MatrixOrigin's Git4Data paper, which proposes adding Git-style version control to existing SQL databases built on LSM...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4b46effbd3dfd467a47449858b8bd61f?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4b46effbd3dfd467a47449858b8bd61f?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"DoltHub Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"DoltHub Blog","logo":"https://media.daily.dev/image/upload/s--LXDlvjS4--/f_auto,q_auto/v1780213587/logos/dolthub-blog?_a=BAMAMiWQ0","url":"https://daily.dev/sources/dolthub-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/what-is-git4data--smb6mm89e","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,version-control","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"DoltHub Blog","item":"https://daily.dev/sources/dolthub-blog"},{"@type":"ListItem","position":3,"name":"What is Git4Data?"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/what-is-git4data--smb6mm89e#faq","mainEntity":[{"@type":"Question","name":"What tradeoffs does Git4Data have compared to Dolt for database version control?","acceptedAnswer":{"@type":"Answer","text":"Git4Data avoids compacting data objects referenced by named snapshots to preserve diffing efficiency, but this means tables can grow unbounded and tombstoned rows can never be removed from storage, since compaction is the only mechanism to physically delete them. Every new snapshot also forces a data flush, so query performance degrades as the number of snapshots in a table's history grows, unlike Dolt's bounded Prolly Tree structure. Engineers weighing version-controlled database designs can track this kind of tradeoff analysis on daily.dev."}},{"@type":"Question","name":"Why can't LSM-tree based databases achieve efficient diff and merge like Dolt's Prolly Trees?","acceptedAnswer":{"@type":"Answer","text":"LSM-trees lack history independence, meaning two tables with identical data but different histories will not share the same underlying data objects unless one was explicitly branched from the other. This forces full table scans when diffing tables with no common history or when the same insert happens independently on two branches, since the database can't recognize the rows as identical without comparing object contents. Developers comparing storage engines for branching databases can follow deep dives like this on daily.dev."}},{"@type":"Question","name":"How does Dolt's merge performance scale compared to the size of the diff?","acceptedAnswer":{"@type":"Answer","text":"Dolt merges scale with the number of non-overlapping modified ranges rather than the overall table size or the size of the change itself. If two branches modify distinct ranges of the primary key space, merging is O(logN) relative to table size regardless of how large the actual changes are, a result of Dolt's fast-merge implementation rather than materializing and comparing full table contents. Teams benchmarking database merge performance can keep up with findings like this through daily.dev."}}]} ```