Dolt

A MySQL-compatible SQL database with Git’s model built in: every table can be branched, diffed, merged, pushed and pulled, and every commit keeps the whole database as it was.

What it is: Relational databases
Used for: Version control
Type: Open source
Made by: DoltHub, Inc.
License: Apache 2.0
Facts checked: 24 October 2026

What it is

Dolt is a SQL database you run as a server (dolt sql-server, on port 3306) and connect to with ordinary MySQL clients and drivers, or use from a command line that copies Git’s: dolt add, dolt commit, dolt branch, dolt merge, dolt push. Inside SQL the same operations are stored procedures such as CALL dolt_commit() and CALL dolt_merge(), and history is read through system tables: dolt_log lists commits, dolt_diff_<table> shows how each row changed between commits, dolt_history_<table> shows a row at every commit, and SELECT … AS OF 'main~1' queries a table as it was at a branch, commit or timestamp. Merges work cell by cell; when both sides changed the same cell, the row lands in dolt_conflicts_<table> with base_, our_ and their_ columns to resolve in SQL. A commit is a snapshot of the whole database, separate from SQL transactions, so you choose when to record one.

Underneath, every table, secondary index and schema is a prolly tree (“probabilistic B-tree”), a structure first built for Noms. Rows are sorted by primary key and cut into chunks of about 4 KB at boundaries chosen by a hash of their contents, so the tree’s shape depends only on the data, not on the order of edits. Each chunk is stored once under its content hash, which lets a new commit share every unchanged chunk with the old one, and a diff skips any subtree whose hash matches, so it costs time in proportion to the changes, not the table. Dolt 2.0, released in May 2026, turned on automatic garbage collection and a compressed archive format by default, and DoltHub reports it about 8% faster than MySQL on sysbench. Doltgres, a Postgres-compatible server on the same engine and storage, reached 1.0 in August 2026. DoltHub, Inc. also runs DoltHub (a hosting site for Dolt databases, like GitHub for code), DoltLab (the same, self-hosted) and Hosted Dolt (managed servers).

Why teams pick it

Branches, diffs and merges of live data in SQL, so changes to reference data, configuration or an agent’s edits can be reviewed and merged like a pull request, or rolled back with dolt_reset
Every commit stays queryable: AS OF and dolt_history_<table> answer “what did this row look like last Tuesday, and who changed it?” without audit tables
Structural sharing keeps history cheap, and a diff costs time in proportion to what changed, not to the size of the table
Speaks the MySQL protocol, with Doltgres for Postgres clients; it can also run as a replica of an existing MySQL primary to add history without migrating

Watch out for

Meant to run on one primary server: there is no multi-primary write path, so going beyond one machine means sharding in the application
Replication is primary-to-standby: remote-based replicas are for reads only, and with direct replication an unplanned failover may lose data; users, grants and DROP DATABASE are not replicated
Compatible, not the real thing: MySQL 9.0’s default authentication needs extra setup, and Doltgres 1.0 has limited extensions (no PostGIS yet), no row-level security and is about 2.7 times slower than Postgres by DoltHub’s own figures
Keeping every version still costs disk: garbage collection reclaims only chunks that no commit refers to, so tables rewritten often keep growing with their history

Good for

Versioned data with branchesCommits, branches and cell-by-cell merges are SQL procedures, diffs and history are system tables, and AS OF reads any past commit.

Specs

Compare with alternatives →

Data model: Relational tables kept as prolly trees, versioned by commit
Query language: MySQL-compatible SQL, plus dolt_* procedures and system tables
Client protocol: MySQL protocol; PostgreSQL protocol through Doltgres
Secondary indexes: Secondary indexes, each its own prolly tree
Transactions: SQL transactions, separate from Dolt commits
How it scales: One primary server; going further means sharding in the application
Replication: Primary to standby: remote-based read replicas, or direct-to-standby
Storage engine: Prolly trees of content-addressed chunks of about 4 KB
Ways to run it: Self-hosted dolt sql-server, Hosted Dolt, or DoltLab

Alternatives

What all relational databases have in common →Compare side by side →

MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.+1 MariaDB

NeonCommercialAlso good for versioned data with branchesServerless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.

XataCommercialAlso good for versioned data with branchesA platform that runs unmodified Postgres on Kubernetes with copy-on-write branches at the storage layer, scale to zero, and anonymized copies of production for development.

PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.+2 Citus, Omnigres

Alibaba Cloud PolarDBCommercialAlibaba Cloud’s cloud-native relational databases: MySQL- and PostgreSQL-compatible clusters whose compute nodes share one copy of the data on distributed storage, plus PolarDB-X, a distributed MySQL-compatible edition.

CedarDBCommercialA PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.

Cloudflare D1CommercialCloudflare’s serverless SQL database that speaks SQLite, runs each database inside a Durable Object, and bills by rows read and written rather than by the hour.

CloudNativePGOpen sourceA Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.

CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.

GelArchivedOpen sourceA “graph-relational” database, called EdgeDB until 2025, that runs on Postgres but gives it a typed object schema, automatic migrations and its own query language, EdgeQL, which compiles each query to one SQL statement.HerdDBDormantOpen sourceA SQL database in Java that runs inside an application’s JVM or as a replicated cluster, with Apache BookKeeper as its write-ahead log and ZooKeeper for metadata.

PatroniOpen sourceA Python agent beside each Postgres server that elects one primary through etcd, Consul, ZooKeeper or Kubernetes, and fails over when it dies.

Percona OperatorsOpen sourceFour free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.

PGO (Crunchy Postgres for Kubernetes)Open sourceCrunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative PostgresCluster resource on top.

PlanetScaleCommercialManaged MySQL on Vitess and managed Postgres, with schema changes shipped through branches and deploy requests.

ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.

SQLiteOpen sourceA complete SQL database in a library and a single file, with no server to run.

TiDBOpen sourceA distributed SQL database that speaks the MySQL protocol, stores rows in TiKV, a Raft-replicated key-value store, and can keep a columnar copy in TiFlash for analytics on live data.

TursoOpen sourceA from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.

VitessOpen sourceA proxy layer, born at YouTube, that shards MySQL across many servers while the app still sees one database.

YugabyteDBOpen sourceA distributed SQL database that runs PostgreSQL’s own query layer on top of DocDB, a sharded, Raft-replicated storage engine built on RocksDB.

How it fits with other technologies

What Dolt uses

Branch, change, diff and merge a table, all in SQL · sql

CALL dolt_checkout('-b', 'price-update');
UPDATE products SET price = price * 1.05 WHERE category = 'pumps';
CALL dolt_commit('-am', 'Raise pump prices 5%');

-- what changed, row by row, between main and the branch
SELECT from_price, to_price, to_sku, diff_type
FROM dolt_diff('main', 'price-update', 'products');

-- review done: merge it
CALL dolt_checkout('main');
CALL dolt_merge('price-update');

-- the table as it was one commit ago, and every past value of one row
SELECT * FROM products AS OF 'main~1' WHERE sku = 'PUMP-ROD-7';
SELECT commit_hash, committer, commit_date, price
FROM dolt_history_products WHERE sku = 'PUMP-ROD-7';

See it in a real stack

No architecture uses Dolt yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2015–2026

Sharing a dataset usually meant mailing CSV files or dumps: nobody could see what had changed between two copies, merge two people’s edits, or go back to last week’s version. Code had solved this with Git. In 2015 Attic Labs began Noms, a content-addressed, versioned database, and invented the prolly tree for it. Salesforce bought Attic Labs in January 2018 and Noms development stopped.

Liquidata, the company that became DoltHub and is led by Tim Sehn, was incorporated in February 2018, and its founders started full time that August, looking for a way to share data with the emphasis on version control. In October 2018 one of them, Brian, put a Git-style command line on top of Noms, called it Dolt in November as a nod to Git, and launched it in August 2019, with DoltHub, a site for hosting and sharing Dolt databases, following in September. The company renamed itself DoltHub in 2020.

From 2021 Dolt set out to be a production OLTP database rather than a data-sharing tool. The storage format inherited from Noms was the bottleneck, so the team wrote a new one between 2021 and March 2023 and declared Dolt 1.0 production-ready in May 2023. Doltgres, the Postgres version, followed as an alpha in November 2023 and reached 1.0 in August 2026, and Dolt 2.0 in May 2026 claimed to be faster than MySQL on sysbench.

Why it’s built this way

Copy Git’s commands and model exactly: Developers already know branch, commit, merge, push and pull. Putting Git’s command line on Noms was the moment the founders saw a product, and they named it Dolt in Git’s honour.
Prolly trees for all data: A B-tree’s shape depends on the order of inserts, so two identical tables could be stored differently. Chunking by content hash makes equal data produce equal chunks, which gives deduplication across versions and diffs that skip unchanged subtrees.
MySQL compatibility first: Being a drop-in replacement meant existing clients, ORMs and tools worked from day one, and Dolt could run as a replica of a MySQL primary. Postgres support came later as a separate product, Doltgres, built on the same engine.
Rewrite the storage format for OLTP: The Noms format was too slow for transactional workloads. The new format, built from 2021 to 2023, forced a one-time migration of old databases but made Dolt an order of magnitude faster.

Timeline

2015
First commit to Noms, which introduces the prolly tree
2018
Liquidata founded; a Git command line on Noms becomes Dolt
2019
Dolt launches in August, DoltHub in September
2020
Liquidata renames itself DoltHub
2022
DoltLab and Hosted Dolt launch; first version of the new storage format
2023
Dolt 1.0 in May; Doltgres alpha in November
2026
Dolt 2.0 in May; Doltgres 1.0 in August

Sources10 · facts checked 24 October 2026

Improve this page on GitHub