DoltHub shipped DoltLite five months ago as an experiment: a fork of SQLite with the B-tree storage engine replaced by a content-addressed prolly tree, so a plain SQLite database can branch, merge, and diff like a git repository. On August 31 the project hit beta with version 0.50.0.1
There are two stories here. One is that version-controlled SQLite is now stable enough to build on. The other is the process behind it: roughly 2,000 pull requests, much of it written by coding agents running under Gas Town, Steve Yegge's agent orchestrator.1
A fork, but only below the B-tree
The interesting part of DoltLite is where the change sits. Everything above SQLite's B-tree layer, the SQL parser, the analyzer, the file system interaction layer, and the test harness, is stock SQLite. Only the B-tree was swapped out, for a prolly tree backed by a single-file chunk store.1
A prolly tree is a content-addressed B-tree, the same structure that powers Dolt, DoltHub's MySQL-compatible version-controlled database. A tree is immutable: changing a row cannot overwrite a node in place the way a B-tree does, and that immutability is what buys cheap branching and content-addressed diffs.21
That design also avoided the hardest work. DoltHub did not have to write a SQL engine on top of version-controlled storage, the part that made Dolt so much effort. It got SQLite's engine for the cost of writing a version-controlled storage engine in C.1
The C API keeps SQLite's sqlite3_* names. Existing programs port by switching the include and link over to libdoltlite.3 Bindings exist for Python, Ruby, Node and Bun, PHP, .NET, Rust, Swift, Android, and WASM, so the embedded story covers just about every runtime you would want.3
What beta buys you
The announcement frames beta as four promises: storage format stability, SQL compatibility, full version control, and production performance.1
Storage format stability
Getting here took 12 breaking format changes, none of them backward compatible, which meant users had to stay on the same version or dump and reimport their data. The current format has been stable for 57 releases, over three months, and is now considered frozen: any future breaking change gets a supported migration path.1 The on-disk file is a single content-addressed chunk store with magic bytes DLTC, holding prolly-tree chunks, a WAL of chunk and root records, and refs for branches and tags.3
SQL compatibility
SQLite ships an enormous test suite, and DoltLite runs it. The project passes 100% of sqllogictest, 5.8 million queries, and 99.46% of SQLite's 892,277 TCL acceptance tests. The 4,809 divergences all carry a documented reason, and they cluster in three places: tables are keyed by primary key instead of rowid (required for version control), DoltLite has chunks instead of pages, and there is no WAL or journal sidecar.1
Full version control
Branch, merge, diff, rebase, cherry-pick, reset, and tag all work as SQL functions. Remotes work too: dolt_clone, dolt_push, dolt_pull, and dolt_fetch talk to a custom remote, a filesystem or HTTP endpoint, or DoltHub itself, which has hosted DoltLite databases since early August.14
A minimal session looks like this:
SELECT dolt_config('user.name', 'Tim Sehn');
SELECT dolt_config('user.email', '[email protected]');
SELECT dolt_add('users');
SELECT dolt_commit('-m', 'Add users table');
SELECT * FROM dolt_log;
SELECT dolt_branch('feature');
SELECT dolt_checkout('feature');
-- edits, then another commit
SELECT dolt_checkout('main');
SELECT dolt_merge('feature');SELECT dolt_config('user.name', 'Tim Sehn');
SELECT dolt_config('user.email', '[email protected]');
SELECT dolt_add('users');
SELECT dolt_commit('-m', 'Add users table');
SELECT * FROM dolt_log;
SELECT dolt_branch('feature');
SELECT dolt_checkout('feature');
-- edits, then another commit
SELECT dolt_checkout('main');
SELECT dolt_merge('feature');The Dolt Workbench GUI runs against DoltLite too, agent mode included, so you can let an agent loose on your SQLite and call dolt_reset('--hard') if it breaks something.1
Production performance
DoltHub publishes a nightly sysbench-style benchmark comparing DoltLite to stock SQLite straight to the repository. Current numbers: in-memory databases run 10% slower on reads and 60% slower on writes; file-backed databases sit at parity on reads and 10% slower on batched writes. The outlier is small autocommit writes, 3.1x slower, which works out to roughly 400 microseconds per write versus 125 in SQLite. The mitigation is the standard SQLite one: batch writes in a transaction.1
The cost is structural. A prolly tree is immutable, so changing a row re-hashes the path from leaf to root and writes new chunks instead of mutating a page in place.2 A June post measured the prolly tree tax directly: about 20% on reads and 67% on batched writes in the in-memory suite, and 4x on autocommit commits, which only mean anything on disk.2
Built by agents, for the record
The origin story matters because it is easy to misremember. DoltLite started as a lark. DoltHub's Tim Sehn wanted a pet project to try Gas Town on, something real rather than a toy. The launch post called it "entirely vibe-coded" and, at the time, "write-only code," warning that storage format bumps would keep breaking compatibility.5 Five months and about 2,000 pull requests later, it is a beta with a frozen format and a working remote story.1 Whether that makes you more or less interested in agent-written databases, the version-control claims are now verifiable against a stable format rather than a moving target.
Why a version-controlled SQLite matters
Dolt, the original, is a server: you stand up dolt sql-server and point a MySQL client at it. That is the right model for replacing MySQL and the wrong model for local-first apps, where the database has to live on the user's device. DoltLite is the embedded version, a .dylib or .so your application links, or a WASM bundle that runs in a browser tab and keeps data in the origin private file system.6
SQLite sync engines already exist, and DoltHub names them: Turso, PowerSync, ElectricSQL, and cr-sqlite. Their answer to conflicts is usually CRDTs, which merge automatically and quietly. DoltLite's answer is git-style merging instead: same-row edits land in a dolt_conflicts_<table> table and the commit refuses to complete until a human picks a side. For data with audit or rollback requirements, surfacing the disagreement beats resolving it silently.6
Worth a look
If you have been waiting on a git-style sync model for an embedded database, this is the moment it exists in a stable form. Install is one curl:
sudo bash -c 'curl -fsSL https://github.com/dolthub/doltlite/releases/latest/download/install.sh | bash'sudo bash -c 'curl -fsSL https://github.com/dolthub/doltlite/releases/latest/download/install.sh | bash'Or grab a prebuilt binary and start with ./doltlite my.db.3 The storage format is frozen, the SQL compatibility story is specific and public, and the write tax is documented instead of hidden. Good place to start with a five-month-old project.
- DoltLite Beta on the DoltHub blog, August 31, 2026.
- How fast is DoltLite?, DoltHub blog, June 8, 2026.
- dolthub/doltlite repository and README.
- DoltHub now supports DoltLite and Doltgres databases, DoltHub blog, August 7, 2026.
- Introducing DoltLite, DoltHub blog, March 25, 2026.
- Why DoltLite?, DoltHub blog, April 27, 2026.