SQLite With Git Branches Just Hit Beta. Agents Built It in 2,000 PRs.

TL;DR

DoltHub declared DoltLite Beta on August 31, five months and roughly 2,000 pull requests after its March 25 launch. It is a fork of SQLite that rips out the B-tree storage engine and replaces it with a content-addressed prolly tree, which is how your embedded database suddenly grows branch, merge, diff, push, and clone. The Beta gate is concrete: a stable storage format with migration guarantees, a 99.46% pass rate on SQLite's 892,277-assertion TCL suite, and 100% on 5.8 million sqllogictest queries. The part that makes this more than a database release: DoltHub says the project was vibe-coded by a team of agents under Gas Town, Steve Yegge's agent orchestrator, and the whole run is documented in public.

Git semantics, installed through an 8-line incision

DoltLite is not a SQLite-compatible rewrite; it is SQLite, forked. The parser, planner, and execution layer are upstream code. The swap happens below the btree.h seam, where the launch post says the team added about 18,000 lines of new C while modifying just 8 lines of original SQLite. Everything above the storage layer still thinks it is talking to a B-tree.

The prolly tree is the same structure that powers version control in Dolt, DoltHub's Git-for-MySQL database, and you can poke at one in their interactive visualizer. Think of it as a B-tree that went through Git indoctrination: every node is a chunk named by the hash of its contents, so two versions of a database that share most of their rows physically share most of their storage, and computing a diff means walking only the chunks whose hashes differ. That is why the repo can promise diffs in O(changes) rather than O(table size).

The practical surface: a single-file database you can branch, merge, rebase, and cherry-pick locally, plus push, pull, clone, and fetch against DoltHub as a remote. It is Apache 2.0, sitting at 221 GitHub stars as of this writing, with bindings for Python, Ruby, Node.js, PHP, .NET, Rust, WebAssembly, Swift, and Android.

The fleet that built it

Gas Town is the agent orchestrator Steve Yegge open-sourced on New Year's Day 2026. It runs a fleet of coding agent sessions under a coordinating agent called the mayor, with workers called polecats, because when Yegge names infrastructure he names it after Mad Max. DoltHub picked it up in January as an experiment and made DoltLite the test subject.

The March launch post says the alpha was "entirely vibe-coded using Gas Town," and described the result, with admirable honesty, as write-only code: expect format breaks, read nothing, trust the tests. The Beta post closes the loop: about 2,000 pull requests later, DoltHub's take is that a team of agents can in fact carry a storage engine from empty repo to a Beta with compatibility guarantees. The middle of the story is on their blog too, including two weeks of field notes and a Claude-versus-Codex head-to-head on the same backlog.

What Beta actually guarantees

Beta here is a contract, not a mood. Four commitments, per the announcement:

• Storage format stability. The format churned 12 times before Beta; the current one has survived 57 consecutive releases, and future changes now come with supported migration paths.
• SQL compatibility. 99.46% of SQLite's 892,277-assertion TCL test suite passes, and 100% of 5.8 million sqllogictest queries. At the March launch the claim was the 87,000-test acceptance suite; the Beta bar is much stricter.
• Full version control. Branch, merge, diff, rebase, and cherry-pick locally; push, pull, clone, and fetch against a remote.
• Production performance, with published numbers rather than adjectives (next section).

The 0.54% of failing TCL assertions are not mystery bugs: DoltHub documents 4,809 divergences and attributes them to deliberate design differences, mainly keying tables by primary key instead of rowid, chunk-based storage instead of pages, and having no WAL or journal sidecar file. If your tooling assumes a -wal file exists, that assumption is now wrong.

The performance tax, in microseconds

DoltHub published the overhead straight, which is refreshing for a Beta announcement:

The ugliest number hides in autocommit: a single-statement write costs about 400 microseconds against SQLite's roughly 125, a 3.1x gap, because every commit builds content-addressed chunks. DoltHub's guidance is blunt: batch your writes. If your workload is one giant transaction or read-heavy, you barely notice; if it is a hot loop of tiny autocommitted inserts, DoltLite is the wrong tool today.

Why a builder should care

The database itself earns a look if you are anywhere near local-first software. Sync is the unsolved chore of that whole architecture, and a SQLite that natively does push, pull, merge, and O(changes) diffs is a credible answer, embeddable from nine language ecosystems.

There is also an obvious agent-shaped use: give each agent in a fleet its own branch of the application database, let them write freely, and merge the branch that passes review. That is version-controlled state for multi-agent systems, using semantics every developer already knows. DoltHub ships a Workbench GUI with an agent mode pointed at exactly this.

Caveats, straight-faced: this is a five-month-old codebase at 221 stars, the divergence list is 4,809 entries long, atomic commits across multiple attached file-backed databases are unsupported, and Beta is DoltHub's own bar. Read the divergences before you migrate anything that matters.

And as a data point in the agents-writing-serious-software argument, this one is unusually clean: a storage engine is the canonical do-not-vibe-code artifact, the vendor published its test rates and slowdowns instead of a demo reel, and the whole run took five months in public. Draw your own trend line.

Key Takeaways

• DoltLite, DoltHub's Apache 2.0 fork of SQLite with Git-style branch, merge, diff, and sync, reached Beta 0.50.0 on August 31, five months after launch.
• It swaps SQLite's B-tree for a content-addressed prolly tree below the btree.h seam: about 18,000 new lines of C against 8 modified lines of original SQLite.
• The project was built by coding agents orchestrated with Steve Yegge's Gas Town, in roughly 2,000 pull requests, with the process documented on DoltHub's blog.
• Beta guarantees a stable storage format with migration paths, 99.46% of SQLite's 892,277-assertion TCL suite, and 100% of 5.8 million sqllogictest queries.
• Reads are near parity with SQLite; in-memory writes run about 60% slower and autocommitted single writes about 3.1x slower, so batch your writes.
• For local-first apps and multi-agent state, a database with native branches and O(changes) diffs is a genuinely new primitive to build on.

Sources: DoltHub: DoltLite Beta, DoltHub: Introducing DoltLite, DoltLite on GitHub, DoltLite releases, DoltHub remote support, Steve Yegge: Welcome to Gas Town.