Dolt: Git-style version control for SQL databases

Dolt is a MySQL-compatible SQL database with Git semantics built into its core. The same workflow used for code (branch, commit, diff, merge, log) applies directly to database tables. It is a drop-in replacement for MySQL, so any application or tool that connects to MySQL can use Dolt without code changes.

The problem with existing approaches

Standard relational databases (MySQL, PostgreSQL) provide schema enforcement, constraints, and powerful querying, but changes are immediate and often irreversible. There is no built-in diff, no commit history without a custom audit log, and no clean rollback mechanism.

Data in Git (CSV, JSON, YAML files) provides version control with commits and pull requests, but sacrifices all database capabilities. There are no primary keys, no type enforcement, querying requires loading and parsing files, and diffs on CSV files are line-level rather than cell-level, making them hard to review and prone to merge conflicts.

Dolt provides both: a relational database with full SQL and a built-in Git workflow.

How it works: Prolly Trees

Traditional databases use B-Trees optimized for reads and writes but not designed for efficient versioning. Dolt uses Prolly Trees (Probabilistic B-Trees), a content-addressed, immutable data structure where each node is identified by a hash of its contents.

When data changes, Dolt does not modify the existing tree. It creates new parent nodes pointing to the changed data while reusing pointers to unchanged nodes. This means a commit only stores the new data and new pointers, making branches, diffs, and commits nearly instantaneous regardless of database size.

Setup

Install the Dolt CLI following the official installation documentation for macOS, Windows, or Linux. Initialize a repository in a new directory:

mkdir dolt-tutorial && cd dolt-tutorial

dolt init

This creates a .dolt subdirectory for history, configuration, and metadata.

Creating tables and inserting data

Start the interactive SQL shell:

dolt sql

CREATE TABLE employees (
  id INT NOT NULL,
  name VARCHAR(255),
  title VARCHAR(255),
  PRIMARY KEY (id)
);

INSERT INTO employees (id, name, title) VALUES
  (1, 'Alice Johnson', 'Software Engineer'),
  (2, 'Bob Williams', 'Product Manager'),
  (3, 'Charlie Brown', 'Data Analyst');

Update a record:

UPDATE employees SET title = 'Senior Data Analyst' WHERE id = 3;

Exit the shell:

exit;

Tracking changes

Check what has changed:

dolt status

View a structured cell-level diff:

dolt diff

The diff shows which rows and columns changed, not just which lines of text differ. Stage and commit:

dolt add employees

dolt commit -m "Promote Charlie Brown to Senior Data Analyst"

Branching and merging

Create and check out a new branch:

dolt checkout -b add-feature-flags

Make changes on the branch using the -q flag for single queries:

dolt sql -q "CREATE TABLE feature_flags (flag_name VARCHAR(100) PRIMARY KEY, is_enabled BOOLEAN);"

dolt sql -q "INSERT INTO feature_flags (flag_name, is_enabled) VALUES ('new-dashboard', false);"

dolt add feature_flags

dolt commit -m "Add feature_flags table for new dashboard"

Merge back into main:

dolt checkout main

dolt merge add-feature-flags

Audit log

dolt log

This displays every commit with hash, author, date, and message. The full history is also queryable via system tables such as dolt_log, dolt_diff_<tablename>, and dolt_commits, allowing SQL queries over commit history.

Running as a MySQL server

dolt sql-server

This starts a MySQL-compatible server that any ORM, BI tool, or application can connect to on the default port. The version control commands remain available via the CLI while the server runs.

DoltHub

DoltHub is a hosting platform for Dolt databases, analogous to GitHub for code repositories. It supports push, pull, clone, and pull requests for data changes, enabling team-based data review workflows.

Final thoughts

Dolt is most valuable for data that changes over time and needs to be audited, reviewed, or rolled back: application configuration, feature flags, curated reference datasets, and data pipelines where a bad import needs to be undone cleanly. For standard transactional application data where version history is not a requirement, a conventional database remains simpler.

The Prolly Tree implementation means that branching and diffing do not get slower as the database grows, which distinguishes it from approaches that implement versioning through audit triggers or shadow tables.

Source code and documentation are at github.com/dolthub/dolt.

Got an article suggestion? Let us know

Next article

What is PocketBase? Features, Limitations, and Use Cases

Explore PocketBase: an open-source, self-hosted backend with SQLite database, authentication, and file storage in a single file. Learn its features and limitations

→

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.