DoltLite beta: version-controlled SQLite, 2,000 agent PRs

Two things happened in one release. DoltHub shipped DoltLite beta — a SQLite fork that gives you Git-style branching and merging on a SQL database — and disclosed that it took roughly 2,000 pull requests from an agent orchestration system they call Gas Town to get there. The database is the useful part. The build process is the part that tells you where this is going.

What actually happened

DoltLite replaces SQLite's B-tree storage engine with a content-addressed prolly tree, which is what makes structural diffing and merging possible on table data instead of on files. It keeps SQLite's SQL semantics and its public C API surface, so it is a drop-in swap in many cases. Version control is real: branches, commits, merges, diffs, rebases, cherry-picks and resets locally, plus push, pull, clone and fetch against a remote (DoltHub).

The compatibility numbers are the reason to take it seriously. DoltLite passes 100% of sqllogictest — a suite of 5.8 million queries — and 99.46% of SQLite's TCL acceptance tests, with 4,809 known divergences documented rather than hidden. The beta explicitly covers storage format stability, so the on-disk format is not expected to break under you.

It is Apache 2.0, with bindings for Python, Ruby, Node.js, PHP, .NET, Rust, WebAssembly, Swift and Android (GitHub).

Why version-controlled SQLite matters for your business

Every small business runs on data nobody can diff. Price lists. Tax tables. Product catalogs. Shipping zone rules. Commission tiers. Somebody edits a row, something downstream gets weird three weeks later, and there is no git log to run — you are reconstructing intent from a backup taken at 2am on an arbitrary Tuesday.

That is what this fixes. SELECT the diff between two commits of your pricing table. Branch the catalog, let someone stage the seasonal changes, review the diff, merge on launch day. Roll back a bad import as one operation instead of a restore-and-reconcile afternoon. For reference data — the slow-moving tables that quietly control your business logic — this is a better default than a row in Postgres with an updated_at column and hope.

Sober framing, because we do not ship betas into revenue paths: this is beta, it is a fork of the most-tested database on earth but it is still a fork, and 4,809 documented divergences means read the list against your queries. The right first use is a table where a mistake costs a re-import, not a table where a mistake costs an order.

The 2,000-agent-PR detail deserves a note of its own. An agent fleet did not "write a database." It ground through the enormous, mechanical work of making a fork pass millions of existing tests — a task with a machine-checkable definition of done. That is the shape of work agents are actually good at right now, and if you are looking for where to point them in your own codebase, that shape is the answer: high volume, tightly specified, verified by a suite you already trust.

Sources: DoltHub, GitHub.