A database with a commit graph
Dolt stores relational tables while exposing a workflow modeled on Git. You can initialize a database, stage table changes, commit them, create branches, compare revisions, merge work, and push to a remote. A MySQL-compatible server lets existing clients issue ordinary SQL. Version operations appear in SQL as system tables, table functions, and stored procedures, so an application can inspect history without shelling out to the CLI.
That combination is useful when the history is part of the product. A data publisher can distribute a cloneable dataset and accept changes as branches. A team can test a schema migration with matching data before merging it. An automated worker can receive its own branch, make changes, and return a diff that a person reviews. AS OF queries and per-table diff views make old states available without maintaining a parallel audit schema.
Most applications do not need this. If the only requirement is reliable current-state storage behind a MySQL client, standard MySQL has fewer concepts and closer behavioral compatibility. Dolt asks the team to manage a database transaction history and a Dolt commit history. That cost is worthwhile only when branches, merges, or lineage enter the normal workflow.
SQL transactions and Dolt commits are different
The README makes an important distinction: a Dolt commit is not a SQL transaction COMMIT. SQL transactions control visibility and atomicity for database work. Dolt commits record a named point in the database's version history. Autocommit can finish each SQL statement without producing a matching Dolt commit unless the relevant system variable is enabled.
This separation is sensible, but new users can easily carry the wrong mental model from Git. A successful transaction may still leave uncommitted Dolt changes in the working set. A merge may need its own Dolt commit. Teams should decide who creates history commits, how often, and whether application traffic or an external workflow owns that action. Commit author identity also requires a configured name and email.
Branch behavior is exposed inside SQL sessions. One session can check out a branch and modify it while another session remains on main. Queries can read another branch or commit through AS OF, and diff functions compare table rows across revisions. This is more useful than treating database snapshots as opaque files because the differences remain queryable as relational data.
MySQL compatibility is practical, not absolute
Dolt starts a server on port 3306 and works with MySQL-compatible clients. The tutorial uses a MySQL 8.4 client and covers tables, foreign keys, secondary indexes, triggers, constraints, stored procedures, joins, and schema changes. Existing database tools can therefore connect without learning a custom wire protocol.
Compatibility still needs application testing. The README warns that MySQL 9 changed authentication and cannot connect to Dolt by default without configuration. Open issues on 2026-08-22 report triggers becoming detached after RENAME TABLE and trigger metadata failing after a referenced column is renamed. Those reports concern specific rename paths, not all triggers, but migration-heavy applications should reproduce them before switching.
The version graph also changes operational habits. A branch is useful for isolated work but shares the database's fate. Dolt provides separate backup commands, remote repositories, DoltHub for sharing, DoltLab for a self-hosted collaboration service, and a hosted offering. Choose a backup destination and test restoration instead of treating a local branch as disaster recovery.
What happened when we ran it
We cloned commit 0d6b060 into an unprivileged golang:1.24-bookworm container with 3 CPUs and 8 GB of RAM. The checkout contained 2,435 files, about 466,328 lines of source, and occupied 47.2 MB. The Go project lives under ./go/. We found 43 CI workflow files, no Dockerfile, and no top-level tests directory.
Installation succeeded in 96 seconds and installed 449 packages. The build succeeded in 121 seconds. That confirms the source compiled in the clean container with its resolved dependencies.
The test run took 308 seconds and failed with exit code 1. The Go package summary counted 78 passed and 73 failed out of 151. In the supplied final lines, several storage utility packages pass, while github.com/dolthub/dolt/go/utils/batsee and github.com/dolthub/dolt/go/utils/remotesrv are each marked build failed. The log then ends with the overall FAIL. It does not show the compiler errors for those packages or explain the other failures, so there is no basis for assigning one cause to all 73.
This result is a serious contributor warning. The executable built, but the broad test command was nowhere near clean in our environment. Anyone changing Dolt should identify the repository's expected test entry points and prerequisites before treating a plain go test result as representative of CI.
Installation, releases, and health
For users, the installation choices are better than the source-test experience. Dolt publishes binaries for Linux, macOS, and Windows, plus Homebrew, MacPorts, Chocolatey, and Arch packages. Official container images cover the CLI and SQL server even though this source checkout has no Dockerfile. Building manually requires Go, cgo, and a C toolchain, and the command must run from the go directory.
The README is long, concrete, and opinionated. Its walkthrough creates a database, connects with MySQL, commits schema and rows, inspects diffs, recovers a dropped table, branches data and schema changes, merges them, and queries cell lineage. That sequence teaches the two histories better than a feature list would. Dedicated documentation covers concepts and SQL references beyond the front page.
Version 2.3.1 was released on 2026-08-19. Its changes include a backup correction so syncing no longer commits the calling session's open transaction. The repository was pushed on 2026-08-22, and issues and pull requests were updated the same day. GitHub reported 704 open issues and pull requests combined. Current reports include trigger rename correctness and a DOLT_RESET('--hard') regression in 2.3.0, alongside active fixes and dependency updates.
Dolt is easy to understand once a dataset truly needs branches. For ordinary application storage, that requirement should be proven rather than assumed. For reviewable data work, the SQL-accessible history is distinctive enough to justify testing despite the failed repository-wide run.