DoltLite brings Git-style history to SQLite

DoltLite has reached beta after roughly 2,000 pull requests, bringing Git-style version control to an embedded SQLite-compatible database. The project is available as version 0.50.0 after about five months of development, with binaries and language bindings for macOS, Linux, Windows, browsers, mobile platforms and several server-side runtimes.

The project is a fork of SQLite rather than a database that merely imports SQLite data. Its parser, planner, VDBE and higher-level SQL machinery remain upstream-derived above SQLite’s btree.h boundary. DoltLite replaces the B-tree storage layer below that seam with a content-addressed Prolly Tree backed by a single-file chunk store.

This split lets DoltLite retain SQLite’s SQL execution stack and much of its compatibility surface while using the immutable, addressable data structure needed for commits, branches, merges, diffs and time travel. The embedded database exposes Dolt’s version-control operations through SQL functions and virtual tables, without requiring a separate database server or a Git-like wrapper around database files.

What beta changes for deployers

The beta label covers four claims: storage-format stability, SQL compatibility, full version control and production performance. The release notes also say there are no code changes from 0.11.57, suggesting that 0.50.0 is primarily a maturity and support milestone rather than a new engine drop.

Storage compatibility was the largest practical problem during development. DoltLite went through 12 storage-format changes, and earlier revisions could force users to remain on one version or dump and reimport a database. The current format has survived 57 releases, or more than three months, and the project says future breaking changes will have a supported migration path.

SQL compatibility is measurable here. DoltLite passes 100% of sqllogictest’s 5.8 million complex queries and 99.46% of SQLite’s 892,277 TCL acceptance tests, with 4,809 known divergences. Those failures are not presented as random defects: many inspect SQLite internals that DoltLite intentionally changes, including rowid, page layout, write-ahead logging and journal sidecars.

Tables are keyed by primary key rather than rowid to support version control, and the engine stores chunks rather than SQLite pages. WAL and journal tests are skipped because DoltLite does not use those sidecar files. Applications that depend on SQLite’s pager, page format or journaling behavior therefore cannot be treated as drop-in compatible solely because ordinary SQL queries work.

The DoltLite repository documents the engine boundary, C API and build options, including the doltlite.h header, static and shared libraries, and the SELECT doltlite_engine() check, which returns prolly for a native DoltLite build.

Version control is exposed inside SQL

The database includes local operations such as branches, merges, rebases, cherry-picks, resets and diffs. Remote operations include push, pull, clone and fetch, either against a custom remote or DoltHub. The project also includes the Dolt Workbench GUI, including an agent mode that can operate on a database; the source specifically points to dolt_reset('--hard') as a recovery mechanism if an agent makes unwanted changes.

The SQL surface goes beyond basic commit history. dolt_status reports staged and unstaged changes, dolt_diff and dolt_diff_<table> expose data changes, and dolt_schema_diff compares tables, views and indexes. dolt_patch can produce ordered, executable SQLite statements between references, including schema rebuilds where SQLite’s ALTER syntax is insufficient. Per-table history, point-in-time snapshots and blame information are available through virtual tables such as dolt_history_users, dolt_at_users and dolt_blame_users.

The repository also versions repository documents and SQL tests. A fresh repository includes an AGENT.md usage guide, while dolt_docs can store files such as README.md and LICENSE.md under the same commit, branch and merge model as database tables. The dolt_tests table stores assertions that can be run with dolt_test_run().

The design suits local-first applications and tools that need an auditable data history without deploying a database service. It also creates a more substantial integration surface than adding export snapshots to SQLite: application code must account for staging, commit configuration and storage-engine differences where it uses SQLite-specific internals.

Performance trades write speed for history

The published benchmark uses 100,000 rows, Linux x64, five paired invocations per test and microsecond timings. In the file-backed workload, DoltLite’s average read time is lower than SQLite’s in the release table, while its average write time is higher:

The read results are not uniformly faster: DoltLite beats SQLite on point selects, range selects and several scans in this run, but trails on index joins and table scans. The release table’s aggregate oltp_read_only result is 0.84x, while oltp_write_only is 1.53x and oltp_read_write is 1.40x. The project’s accompanying performance report characterizes file-backed reads as near parity and batched writes as about 10% slower, but small autocommit writes are the clear outlier at 3.1x slower.

The reported example puts that cost in concrete terms: about 125 microseconds for a tiny SQLite autocommit write versus about 400 microseconds for DoltLite on a small GitHub runner. Those are still sub-millisecond operations, but write-heavy applications should batch transactions rather than assume ordinary SQLite write behavior.

In-memory performance has a different profile. The project says in-memory DoltLite is 10% slower on reads and 60% slower on writes, while file-backed databases are at parity on reads and 10% slower on batched writes. The benchmark conditions are supplied by the project, not an independent test, so the numbers describe the version-control overhead reported by DoltLite rather than a general performance guarantee across workloads or hardware.

Deployment options and compatibility limits

The same release artifacts include the doltlite CLI, a remote synchronization server, the embedding header, static library and shared libraries. Prebuilt packages cover Apple Silicon macOS and Linux on x86_64 or arm64. Debian and Ubuntu packages are provided for amd64 and arm64, while Windows users can download an x64 tools ZIP.

Language distribution is broader than the core C interface. The repository lists packages for Python, Ruby, Node.js and Bun, PHP, .NET, Rust, browser/WASM, Swift for iOS and macOS, and Android. The bindings expose the bundled SQLite version’s public sqlite3_* API along with Dolt version-control functions, subject to the storage-engine exceptions.

There are some deployment footnotes. Python users need a Python build whose _sqlite3 links a shared libsqlite3; the project warns against Python installations that statically link SQLite, including the Python.org macOS installer and Apple’s system Python. WASM builds with remotes enabled require an Emscripten-compatible socket transport or proxy. Builds can also disable remote clients, and the DOLTLITE_VEC1 option controls whether the native vec1 component is included.

No license or pricing terms are specified in the supplied release material, and the project does not claim that every SQLite extension or application will work unchanged. For US developers, the question is whether branchable, queryable history justifies the write penalty and the incompatibilities around SQLite’s pager and journaling internals. Those trade-offs are documented in the beta release rather than hidden behind an experimental storage format.