Data versioning in 2026: revisit DVC, lakeFS and Dolt before you overwrite another production dataset

Many data teams have lived this week. A nightly job writes a fresh feature table to a shared prefix such as s3://claims-prod/features/current/. In the morning a training run fails, a downstream report shifts, and someone asks: “Which copy of the data produced yesterday’s numbers, and can we get Tuesday’s files back?” The answer is often a dated folder on a laptop, or a silent overwrite with no commit, no branch and no review.

Copying a file is easy. The hard part is treating a dataset as something you can name, isolate, review and restore, so an experiment cannot overwrite what others are reading, a report can be reproduced next quarter, and a bad write can be rolled back without hunting through backups.

This post revisits three tools that people still group under “git for data”: DVC, lakeFS and Dolt. They sit at three different layers, and they are not drop-in replacements. DVC versions large files next to Git through pointer files and a remote cache. lakeFS adds Git-like branches, commits and merges over object storage, leaving the data files in the bucket. Dolt is a SQL database with Git-like versioning and a MySQL-compatible wire protocol. DVC and Dolt remain Apache-2.0. lakeFS Community moved to the Business Source License 1.1 in September 2026, so current Community releases are source-available rather than OSI open source.

Table formats, experiment trackers, quality checks and catalogues come up only as contrast. See the existing comparisons of Iceberg, Delta Lake and Hudi, MLflow, Aim and ClearML, Great Expectations, Soda Core and Elementary, and OpenMetadata, DataHub and Apache Atlas.

The short version

• DVC: Apache-2.0 licence. A Python CLI, library and VS Code extension, originally built at Iterative.ai. Since 18 November 2025 the open-source project has been stewarded by lakeFS (Treeverse), and the repository now lives at treeverse/dvc. It tracks large files beside a Git repo using pointer files, a local cache and remotes such as S3, GCS, Azure Blob or SSH. Best fit when a data science or ML team wants datasets and models versioned next to code, without standing up a data platform.
• lakeFS: Business Source License 1.1 from v1.87.0 (22 September 2026) for the Community edition; every earlier release stays Apache-2.0. A Go server from Treeverse Labs Ltd that presents Git-like repositories, branches, commits and merges over an S3-compatible object store. Data files stay in the bucket; lakeFS stores pointers and metadata. Best fit when many jobs already share prefixes on object storage and you need isolated writes without copying the lake. Community is a single-administrator install. Multi-user access control, SSO and several scale features sit in the paid Team and Enterprise editions.
• Dolt: Apache-2.0 licence, built by DoltHub. A Go SQL database you can fork, clone, branch, merge, push and pull. Git versions files; Dolt versions tables. It speaks the MySQL wire protocol through dolt sql-server (default port 3306), and version control is also exposed as SQL system tables and stored procedures. Best fit when the data is relational and people need row-level diffs, merges and time travel, not when the data is a pile of files in a bucket.

What job is actually being done

“Version your data” hides several jobs that do not share one product category.

• Pin files next to code. Keep a large dataset or model beside a Git commit, without putting the bytes in Git.
• Isolate writes on a shared lake. Let a pipeline or an experiment write to the same logical paths other people read, without overwriting their view.
• Commit a consistent snapshot. Name the exact set of files that produced a report, a feature table or a training run, and restore that set later.
• Review a data change. Show what changed before it becomes the production copy, at file level or at row level.
• Diff and merge tables. Compare two versions of a relational dataset and audit which commit changed a cell.
• Reproduce work. Recreate last Tuesday’s inputs, not only last Tuesday’s code.

A lakehouse table format gives time travel inside one table, which is a different job from branching an object-store prefix or versioning files beside Git. An experiment tracker records runs, parameters and metrics; choosing one is the subject of the earlier comparison. A catalogue helps people find datasets. It does not, by itself, stop the next overwrite.

Why this matters more in 2026

Two of these tools now share a steward

On 18 November 2025, lakeFS announced that it had acquired the DVC open-source project from Iterative.ai. The DVC FAQ says stewardship moved to lakeFS, while DVC stays a separate project, keeps dvc.org, and remains Apache-2.0. The GitHub repository has since moved from iterative/dvc to treeverse/dvc (the old URL redirects). Treeverse is listed as the maintainer in the current pyproject.toml, and the licence file carries a “Copyright 2025 Treeverse” notice.

That FAQ, written in November 2025, still described lakeFS as having an open-source edition. That was true then. It is no longer the full picture for current lakeFS releases.

lakeFS Community changed licence

Starting with lakeFS v1.87.0, published on 22 September 2026 (7:56 PM IST), the Community edition moved from Apache-2.0 to Business Source License 1.1. The licence text says it is not an open-source licence, though each version converts to Apache-2.0 four years after that version is first published. Releases before v1.87.0 stay Apache-2.0 permanently. DVC is unchanged and stays Apache-2.0.

The additional use grant allows production use of the unmodified Community binary for your organisation’s internal purposes. It does not allow a modified lakeFS in production, or hosting or reselling lakeFS (or access to its functionality) to third parties. Treeverse’s announcement walks through those two limits and points questions to hello@lakefs.io.

The same v1.87.0 release removed pluggable IAM and the ACL reference server. Current Community docs describe a single administrator user, created at setup, with one set of credentials for the UI, API and S3 gateway. Additional users, groups, policies and SSO belong to Role-Based Access Control in lakeFS Enterprise. The editions page also lists a lakeFS Team tier, with a five-user, 500 GB and 500 requests-per-second envelope and a 30-day trial.

Overwrites are still the default on many lakes

Shared prefixes named current or latest remain a common way to publish data. That habit collides with training jobs, late corrections and the simple question “what did we actually use?” Branches and commits do not replace backups, quality checks or table formats. They do give you a name for a snapshot and a way to try a write without destroying the previous one.

A small Indian example

Take a thirty-engineer product company in Ahmedabad selling a health insurance claims platform. Data science keeps claim-document images and a fraud-model training set in dated folders, then copies a “final” directory into the training repo by hand. Analytics publishes nightly Parquet files to a shared current prefix that both the fraud job and the finance report read. Product and medical coding maintain a provider-and-procedure reference table in MySQL, and nobody can show which rows changed between last week’s settlement and this week’s. It is a familiar shape: files beside a model repo, a shared lake prefix, and a relational table that people want to review like code.

DVC: files beside Git

History and licence

DVC lives at treeverse/dvc on GitHub. The repository was created in March 2017 and spent most of its life under iterative/dvc. The licence is Apache-2.0. Dmitry Petrov is still listed as the original author; Treeverse is now the maintainer. The latest tagged release at the time of writing is 3.67.1, published on 31 March 2026 (10:36 AM IST) and marked immutable on GitHub. It is a Python tool and requires Python 3.9 or later.

How it works

You initialise DVC inside a Git project with dvc init, then track a file or directory with dvc add. DVC writes a small .dvc metadata file that records a content hash and a path (the project’s own examples show an MD5 digest), moves the bytes into a cache under .dvc/cache, and adds the original path to .gitignore. You commit the .dvc file with Git. Switching versions is git checkout of the pointer, followed by dvc checkout to restore the matching cache contents into the workspace.

To share data you add a remote with dvc remote add and upload with dvc push. Remotes include S3 and S3-compatible stores, GCS, Azure Blob, SSH, and several other backends listed in the docs. Sensitive credentials belong in Git-ignored .dvc/config.local. dvc pull brings the cache down after a git clone or git pull. DVC can also describe pipelines in dvc.yaml and manage experiments on top of Git, which does not replace a dedicated experiment tracker. DVC is not a database and not a data lake. The official guides say as much, and they point readers toward lakeFS when the platform is centred on large-scale object storage.

Where it is strong

• No extra server: it works with the Git host and the object store you already have.
• The review path is familiar. A pull request can show that a dataset pointer changed, even if Git never stores the bytes.
• A good match for datasets and models that belong to one repository.

What to watch

• A Git commit of .dvc files is not the same as having pushed the cache. Another machine will not see the data until dvc push has run.
• It is a repo-centric workflow. If many services read and write the same production prefix, you are asking DVC to do a lakeFS job.
• The latest tag is more than seven months old as of this writing. The repository was still receiving commits in early November 2026, but anyone pinning releases should notice the gap.
• The VS Code extension was scheduled to move from Iterative to Treeverse. Check the marketplace publisher you actually install.

lakeFS: Git-like versioning over object storage

History and licence

lakeFS lives at treeverse/lakeFS. The repository was created in September 2019 and is written in Go. Treeverse Labs Ltd is the licensor. Until v1.86.0 the project was Apache-2.0. v1.87.0 changed the licence to Business Source License 1.1 and removed pluggable IAM and the ACL reference server. The latest Community release is v1.88.0, published on 1 October 2026 (3:05 PM IST). That release stops action hooks from calling internal addresses unless you list them in actions.network.allowed_hosts, and it rejects SigV4 requests with unsigned x-amz-* headers. lakeFS Enterprise follows a separate release line; the documentation lists Enterprise v1.108.0 with assets dated 21 October 2026.

How it works

You point a lakeFS repository at a storage namespace in an object store such as Amazon S3, GCS, Azure Blob, MinIO or another S3-compatible system. User data is stored under a data/ prefix as immutable physical objects. Commit metadata lives under _lakefs/. A separate key-value store holds branches, tags and uncommitted metadata, with drivers for PostgreSQL, DynamoDB and CosmosDB.

A branch is a pointer to a commit plus any uncommitted changes, so creating a branch does not copy the data. Graveler translates a logical path such as lakefs://repo/main/path/file into the current physical object. An overwrite writes a new physical object and keeps the old one, so earlier commits still resolve. The S3 gateway implements a compatible subset of the S3 API, so many existing tools can use lakeFS by changing the endpoint. Native clients (the Python SDK, lakectl, the Spark integrations) ask lakeFS for metadata and then read or write the object store directly, often through pre-signed URLs.

Merges are three-way comparisons at file granularity. If both sides changed the same file differently, you get a conflict. Optional source-wins and dest-wins strategies resolve every conflict the same way; format-aware merges are described as future work. Hooks can run on commit and merge. The Community server is a single stateless binary that serves the UI, the OpenAPI server and the S3 gateway on one port.

Where it is strong

• You can branch a large lake without duplicating it, then merge a validated write into production.
• Existing S3-speaking jobs often need only a new endpoint and credentials.
• A commit gives you a reproducible view of many files together, not only one table.

What to watch

• Current Community releases are source-available under BSL 1.1. Read the additional use grant if you fork the code, offer lakeFS outside your organisation, or run a modified build in production.
• Community has one administrator. Separate credentials, SSO or least-privilege policies are a Team or Enterprise conversation.
• You operate a service: lakeFS servers, a metadata store, and garbage collection of objects that no commit still references.
• Merges compare whole files. Two jobs that rewrite the same Parquet file will conflict even if the rows could have been combined.
• If you already run action hooks, read the v1.88.0 network defaults before you upgrade.

Dolt: a SQL database that versions tables

History and licence

Dolt lives at dolthub/dolt. The repository was created in July 2019. The licence is Apache-2.0. DoltHub builds it, and the README credits ideas and code from the earlier Noms project. The latest release at the time of writing is v2.7.2, published on 6 November 2026 (2:00 AM IST). The previous minor bump, v2.7.0 on 5 November 2026 (3:54 AM IST), changed how some schema-merge conflict artefacts are stored. Those artefacts cannot be read by older Dolt versions, which is why the project raised the minor version.

How it works

You can use Dolt from a Git-like CLI (dolt add, dolt commit, dolt branch, dolt merge, dolt push, dolt pull) or from SQL. dolt sql-server starts a MySQL-compatible server on port 3306 by default. Official docs say any MySQL client should be able to connect, and they maintain a list of clients they have tested. The README recommends MySQL 8.4 clients. MySQL 9.0 changes authentication and cannot connect to a default Dolt server unless you configure caching_sha2_password.

Version control in SQL uses stored procedures such as dolt_add and dolt_commit, and system tables such as dolt_log, dolt_status and dolt_diff_<table>. You can query a table AS OF a branch or commit, inspect cell lineage, and reset or revert a bad change. A Dolt commit is separate from a SQL transaction COMMIT. You can push a database to a remote the same way you push a Git repo. DoltHub hosts shared databases, DoltLab is a self-hosted version of that experience, and Hosted Dolt is a managed server. Dolt can also run as a replica of MySQL. DoltHub publishes Doltgres as a separate beta project for the PostgreSQL wire protocol; it is not a fourth tool in this comparison.

Where it is strong

• Row-level diffs and merges, including schema changes on a branch, match how people already think about tables.
• Time travel and lineage are ordinary SQL, so existing MySQL clients and workbenches keep working.
• Reviewing a data change can look like reviewing a pull request, through dolt_diff or on DoltHub and DoltLab.

What to watch

• Dolt versions tables inside a database. It is the wrong tool for a lake of images, logs or Parquet files on object storage.
• “MySQL compatible” is a working protocol and dialect goal, not a promise that every MySQL behaviour is identical. Test the queries and clients you actually run.
• v2.7.0 and later write some schema-merge conflict artefacts that older binaries cannot read. Upgrade replicas together.
• You still have a database to run: authentication, backups, capacity and failover. The hosted options are commercial products around the Apache-2.0 engine.

Side by side, without a table

• Layer. DVC versions files beside Git. lakeFS versions an object-store namespace. Dolt versions SQL tables.
• Licence today. DVC and Dolt: Apache-2.0. lakeFS Community from v1.87.0: BSL 1.1, converting to Apache-2.0 after four years. Older lakeFS tags remain Apache-2.0.
• What you operate. DVC: a CLI and a cache remote. lakeFS: a stateless server plus a metadata store, in front of a bucket. Dolt: a database process, or a hosted Dolt server.
• How people collaborate. DVC: Git pull requests on pointer files, plus dvc push and dvc pull. lakeFS: branches and merges on the lake, with hooks on commit. Dolt: branches, SQL diffs and pull requests on tables.
• Best input. DVC: datasets and models owned by one repo. lakeFS: shared prefixes already living on S3-compatible storage. Dolt: relational data that should be queried, diffed and merged as rows.
• Main risk. DVC: thinking a Git push shipped the data, or stretching it into a multi-writer lake. lakeFS: ignoring the BSL terms and the single-user Community limit. Dolt: pouring a file lake into a SQL engine.

How to choose

• If the data belongs to one ML or data-science repository and you already think in Git commits, start with DVC. Add a remote you control, and make dvc push part of the same habit as git push.
• If the data already lives on object storage, several pipelines share it, and copying the lake is not realistic, look at lakeFS. Use Community to learn the model on an internal install if the BSL terms fit. Budget for Team or Enterprise when you need more than one administrator, SSO or the scale features on the editions page.
• If the data is a table that people query in SQL, and the pain is “who changed this row and can we merge two edits?”, use Dolt. Connect with a MySQL 8.4-compatible client and practise branch, diff and merge on a copy of one reference table.
• Do not pick a logo because a slide said “git for data”. Pick the layer that matches where the bytes already live.

For the Ahmedabad team, a sensible split is DVC on the fraud-model repository, lakeFS in front of the shared claims prefix so nightly writes land on a branch and merge after checks, and Dolt for the provider-and-procedure reference table so coding changes can be reviewed as row diffs. Three tools, three jobs.

Common mistakes

• Treating the three tools as substitutes. They version different things.
• Dated folders named final. That is a copy, not a commit.
• Pushing DVC pointers without pushing the cache. The next clone looks complete and then dvc pull fails.
• Using DVC as the access layer for a shared production prefix. The DVC docs themselves send that workload to lakeFS.
• Assuming lakeFS is still Apache-2.0. Current Community releases are BSL 1.1, and Community is a single-administrator product.
• Expecting lakeFS to merge Parquet or CSV at row level. It merges files.
• Loading an object-store lake into Dolt. Use Dolt where SQL tables are the natural shape.
• Confusing table-format time travel with isolated branches. Iceberg, Delta Lake and Hudi snapshot a table. They do not give you a Git-like branch over a mixed prefix of files.

A practical starting plan

• 1. Write down the job in one sentence: files beside Git, a shared lake prefix, or a SQL table that needs diffs.
• 2. List the production paths that are overwritten today, and who reads them.
• 3. Pick one dataset and name a person who owns its versions for the next month.
• 4. On that dataset only, install the matching tool and create a named snapshot of last week’s good copy.
• 5. Change the publish step so “current” is a branch, a merge or a DVC commit, not an in-place overwrite.
• 6. Practise a restore: can you recreate last Tuesday’s inputs from a commit, a lakeFS ref or a Dolt AS OF query?

No hands-on drill

No hands-on drill was run for this post, and nothing was installed or tested. The facts come from each project’s repository, licence, releases and official documentation, read on 8 November 2026, with release dates converted to IST.

Closing

The revisit is moving from a folder named current to a habit of naming, isolating and restoring data. Learn which layer you actually need, unlearn the idea that one “git for data” product covers files, lakes and databases, re-learn how commits and branches work at that layer, practise on one dataset you can afford to get wrong, and apply the same rule wherever production data is overwritten today. The goal is simple: when someone asks what produced last Tuesday’s numbers, you should answer with a commit, not with a guess.

Sources

• DVC repository: https://github.com/treeverse/dvc
• DVC repository (legacy URL, redirects): https://github.com/iterative/dvc
• DVC licence file (Apache-2.0): https://github.com/treeverse/dvc/blob/main/LICENSE
• DVC releases (3.67.1, 31 March 2026): https://github.com/treeverse/dvc/releases
• DVC pyproject.toml (maintainers, Python requirement, licence): https://github.com/treeverse/dvc/blob/main/pyproject.toml
• What is DVC: https://dvc.org/doc/user-guide/what-is-dvc
• DVC remote storage: https://dvc.org/doc/user-guide/data-management/remote-storage
• DVC data versioning guide: https://dvc.org/doc/start/data-management/data-versioning
• DVC joins lakeFS FAQ (18 November 2025): https://dvc.org/blog/dvc-joins-lakefs-your-questions-answered/
• lakeFS repository: https://github.com/treeverse/lakeFS
• lakeFS licence file (Business Source License 1.1): https://github.com/treeverse/lakeFS/blob/master/LICENSE
• lakeFS releases (v1.88.0, 1 October 2026; v1.87.0, 22 September 2026): https://github.com/treeverse/lakeFS/releases
• lakeFS architecture: https://docs.lakefs.io/concepts/architecture/
• lakeFS internals: https://docs.lakefs.io/concepts/internals/
• lakeFS editions: https://docs.lakefs.io/editions/
• lakeFS Community access control: https://docs.lakefs.io/security/access-control-lists/
• lakeFS authentication: https://docs.lakefs.io/security/authentication/
• lakeFS Enterprise v1.108.0 notes (21 October 2026): https://docs.lakefs.io/releases/lakefs-enterprise/1.108.0/
• lakeFS Business Source License announcement (22 September 2026): https://lakefs.io/blog/lakefs-business-source-license/
• Dolt repository: https://github.com/dolthub/dolt
• Dolt licence file (Apache-2.0): https://github.com/dolthub/dolt/blob/main/LICENSE
• Dolt README: https://github.com/dolthub/dolt/blob/main/README.md
• Dolt releases (v2.7.2, 6 November 2026 IST; v2.7.0, 5 November 2026 IST): https://github.com/dolthub/dolt/releases
• What is Dolt: https://docs.dolthub.com/introduction/what-is-dolt
• Dolt SQL server: https://www.dolthub.com/docs/sql-reference/server/
• Dolt supported clients: https://www.dolthub.com/docs/sql-reference/supported-clients/