Dolt 2.0 Brings Automatic Garbage Collection and Versioned Vectors to Git for Data

The Release

DoltHub shipped Dolt 2.0, the largest revision of its version-controlled SQL database since the project reached 1.0. Dolt is a MySQL-compatible database that treats data the way Git treats source code, with branches, commits, merges, diffs, and clones as first-class operations. The 2.0 release, covered by InfoQ on July 18, focuses on the two areas that have held the project back in production: storage growth and raw query speed. It adds automatic storage optimization, a new on-disk format, and beta support for version-controlled vector indexes. Crucially for existing users, the company says 2.0 is fully backward compatible with every 1.0 release, so no manual migration command is required to adopt it on live databases.

Founder and chief executive Tim Sehn has been candid about the problem the release targets. "Dolt makes a lot of disk garbage, especially during import," he said, warning that "adding extra garbage can eat through your disk very quickly." Version control is expensive by nature, because keeping history means keeping old versions of rows and tables around. For a database that markets itself on branching production data and rolling back mistakes, uncontrolled disk growth was a real barrier to serious deployments. Dolt 2.0 answers with automatic garbage collection that reclaims space in the background and a compression scheme that shrinks the footprint substantially, changing the operational math for teams that were wary of the storage bill.

The Archives Format

The centerpiece is a new on-disk format the team calls archives. It applies dictionary compression to deduplicate data across the database, and DoltHub reports it cuts the storage footprint by 30 to 50 percent depending on the workload. For a version-controlled store, deduplication is especially valuable, because successive commits often differ by a small fraction of the rows, and naive storage would keep near-identical copies. By compressing against a shared dictionary, archives keep the cost of history closer to the cost of the changes themselves. Combined with automatic garbage collection, the format aims to make long-lived Dolt databases behave more like a conventional store from a capacity-planning perspective, which is what a serious production evaluation ultimately requires.

This matters because the storage story is what separates a novelty from an operational tool. Teams evaluating Dolt for audit trails, data pipelines with rollback, or reproducible analytics need to know that enabling history will not quietly triple their disk usage over months of commits. Simon Spati, a data engineer who has written about the space, argues the appeal is broader than any single feature. "Git-like workflows are becoming table stakes," he said, pointing to "significantly better change management, testing on production data, fast rollbacks, isolated experiments, and most importantly, peace of mind when deploying changes." The archives format is what makes those workflows affordable enough to run continuously rather than as an occasional experiment.

Closing the Gap With MySQL

The other headline is speed, and here the trajectory is more striking than the current number. Sehn recounted where the project started. "We started at about 10X slower on reads and 20X slower than MySQL," he said. "We've worked tirelessly to improve Dolt's performance and we are now 13% faster than MySQL on writes and 5% faster on reads." Closing a 10 to 20 times gap and then edging ahead of the reference implementation took years of engineering on the storage engine and query path. For a database whose entire premise is added version-control machinery, matching and beating a mature engine like MySQL on raw throughput removes the obvious objection that keeping history must cost performance.

We would still advise teams to benchmark against their own workloads before drawing conclusions, since the figures come from DoltHub's sysbench runs rather than a neutral third party. Synthetic benchmarks rarely capture the access patterns of a specific application, and version-control features add overhead that shows up under heavy branching and merging. Even so, the direction is clear and the claim is falsifiable, because anyone can run sysbench against both engines and check the result. For organizations that dismissed Dolt on performance grounds a couple of years ago, the 2.0 numbers are reason enough to run a fresh evaluation, particularly for write-heavy pipelines where the reported 13 percent edge would compound over time.

Version-Controlled Vectors

Dolt 2.0 also steps into AI infrastructure with beta support for version-controlled vector indexes, built on MariaDB's Vector type. DoltHub claims Dolt is the only database that version-controls vectors, which is a pointed pitch at teams building retrieval systems for AI agents. Embedding stores change constantly as documents are added, re-chunked, and re-embedded, and today most teams have no clean way to snapshot, branch, or roll back an index. Putting vectors under the same commit-and-branch model as the rest of the data lets teams reproduce exactly which embeddings a model saw, test a re-embedding on a branch, and revert if quality drops. For regulated AI deployments, that reproducibility is a governance feature as much as an engineering one.

The vector support carries a beta label, and DoltHub says it will stay there until remaining gaps in the read path are closed, so we would keep production use cautious for now. The strategic logic is sound, because as retrieval-augmented systems move into enterprises, the data feeding them needs the same lineage and rollback guarantees teams expect from any system of record. A database that already speaks Git for tables extending that model to embeddings is a natural fit. Whether Dolt wins that market depends on performance at scale and on how quickly the vector read path matures, yet the positioning stakes out ground the incumbent vector databases have largely left open to a challenger.

A Maturity Release

Zooming out, Dolt 2.0 reads as a maturity release. The 1.0 line proved the concept that a database could offer Git semantics without abandoning SQL compatibility. The 2.0 work addresses the practical objections that kept it out of production: storage bloat, a performance deficit, and the absence of vector support. None of these is glamorous, and that is the point. Enterprise adoption of an unusual database hinges on the boring guarantees, capacity that stays predictable, throughput that clears the incumbent, and an upgrade path that avoids a forced migration. By clearing those bars in a single release, DoltHub moves Dolt from an interesting demo toward a defensible option for change-sensitive data.

The obvious uses are the ones where losing or corrupting data is expensive and where the ability to branch and roll back has real value: financial reference data, configuration and policy stores, machine learning feature and label sets, and audited pipelines. In each case the version-control model turns a class of operational accidents into a simple revert. We remain unconvinced that most transactional applications should trade a battle-tested engine for Dolt yet, and the vector features need time to settle. For the specific problem of managing data that must be reproducible and auditable, though, Dolt 2.0 is the strongest the project has looked, and it earns a place on the evaluation shortlist.