Dolt: Git for Data
A SQL database that you can fork, clone, branch, merge, push, and pull just like a Git repository.
- Source repo
- dolthub/dolt
- Stars
- ★ 25k
- Last updated
- 1d ago
- License
- Apache-2.0
- Primary language
- Go
- FA score
- 55/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changes
- Cost
- Free, no paid service needed
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- Teams collaborating on database schema and seed data with Git-like branching, merging, and review workflows.
- Not a fit if
- Teams needing full MySQL feature parity, as some storage engines and features may be unsupported
- Teams wanting to reuse existing MySQL data files without a migration
- Production workloads with very large datasets that demand top performance
- Source review
- 55/100 · Major gaps 1 safety controls not found
What does this agent do, and when should you use it?
Dolt is an open-source SQL database with Git-style version control for tables. It supports branching, merging, history, and rollback, and is MySQL-compatible, allowing you to use standard MySQL clients. The project includes a command-line tool (dolt) and a SQL server (dolt sql-server) with system tables and stored procedures for version control operations. Dolt also enforces data integrity with foreign keys, check constraints, and joins. It powers DoltHub for sharing databases, DoltLab for self-hosting, and Hosted Dolt for managed servers. Dolt is ideal for collaborative database development, data auditing, and AI agent memory storage.
Dolt provides a CLI tool (dolt) with Git-like commands (init, add, commit, branch, merge, push, pull, etc.) for tables. It includes a MySQL-compatible server (dolt sql-server) and supports connecting via standard MySQL clients. Within SQL, version control is exposed via system tables (dolt_log, dolt_status, dolt_diff) and stored procedures (dolt_add, dolt_commit, dolt_checkout, dolt_merge). For example, users can execute call dolt_commit('-m', 'message') to commit, call dolt_checkout('-b', 'branch') to create a branch, and use select * from dolt_diff('main','modifications','employees') to diff branches. It also supports querying historical data with AS OF, e.g., select * from employees as of 'modifications'. Additionally, Dolt provides history tables (dolt_history_employees) for granular cell-level lineage.
- Teams collaborating on database schema and seed data with Git-like branching, merging, and review workflows.
- Auditing database changes to track when and how each data cell changed over time.
- Building reproducible data pipelines with versioned database snapshots.
- Providing persistent and versioned memory for AI agents.
- Importing CSV files and managing them with Git commands.
- Syncing database structures across development, staging, and production environments.
How do you install or deploy this agent?
Install Dolt: On Linux or Mac, run: sudo bash -c 'curl -L https://github.com/dolthub/dolt/releases/latest/download/install.sh | bash' or use brew install dolt (Mac). On Windows, download the latest .msi file. To build from source: clone the repo, cd into go directory, and run go install ./cmd/dolt.
How do you use this agent?
After installation, configure user: dolt config --global --add user.email [email protected] and dolt config --global --add user.name "YOUR NAME". Start the server with dolt sql-server. Connect with a MySQL client: mysql --host 127.0.0.1 --port 3306 -uroot. Create database and tables, then use SQL procedures for version control: call dolt_add('table1', 'table2'); call dolt_commit('-m', 'Initial commit'); view history: select * from dolt_log; branch: call dolt_checkout('-b', 'new-branch'); merge: call dolt_merge('branch-name'); For more details, refer to the official documentation.
What are this agent's strengths and limitations?
- Full version control for database tables: branch, merge, rollback, similar to Git.
- MySQL compatibility, so existing MySQL tools and clients can be used.
- Cell-level lineage and auditing through history tables and diffs.
- Enforces data integrity with foreign keys, triggers, check constraints, etc.
- Version control operations are exposed via SQL, making integration with apps easier.
- Requires learning Dolt-specific version control concepts and commands.
- May not support all MySQL features (e.g., certain storage engines).
- Storage format differs from standard MySQL, potentially complicating migration.
- Performance may be lower for large datasets compared to traditional databases.
How does this agent compare with similar options?
Dolt is similar to Git and MySQL but combines both. Compared to Git, it versions tables instead of files; compared to MySQL, it adds version control. There is no direct alternative.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Dolt: Git for Data This agent | 55 · Major gaps | CLIFree | ★ 25k | 1d ago | Go | — |
| Astronomer Agents: AI Agent Toolkit for Airflow Data Engineering | 46 · Major gaps | Agent plugin / skillFree + model costs | ★ 454 | 11d ago | Python | Claude Code |
| CocoIndex | 49 · Major gaps | Library / SDKFree + model costs | ★ 12k | 1d ago | Rust | — |
| Agent Memory Benchmark (AMB) | 39 · Major gaps | CLIFree + model costs | ★ 153 | 5d ago | Python | — |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: Dolt provides version control features including branching, merging, rollback, etc., with rollback capability well supported (3). Source attribution is partially supported via commit logs and author info (2). Least privilege is partially supported with user and grant management but no explicit default or least privilege principle (1). User confirmation is absent (0). Data flow transparency is partially supported with logs and system tables but no explicit data flow description (1). Sensitive data handling is partially supported with security policy and TLS but no explicit sensitive data protection (1). Dependency security is partially supported with dependency update workflow but no vulnerability scanning evidence (1). External effects are partially supported with cluster replication and remote operations but no explicit control (1).
Evidence shows: Self-consistency is adequate with consistent README and tests but not fully verified (2). Dependency availability is partial with dependency management but no availability guarantee (1). Failure messages are adequate with error matching in tests but not comprehensive (2).
Evidence shows: Audience and scenarios are clear for data versioning with multiple use cases (2). Capability boundaries are defined via command list and docs but not explicit limitations (2). Trigger precision is clear in CLI and SQL but no automation triggers (1). Environment fit supports multiple platforms and Docker (2).
Evidence shows: Information architecture is clear with README and docs (2). Install notes are detailed (3). Naming stability is consistent (2). Examples and FAQ have examples but no FAQ (2). Known limitations are not explicitly listed (1). License is Apache-2.0 (3). Versioning and changelog have version command but no changelog (1). Maintenance responsibility has security contact and community (2).
Evidence shows: Output usability is adequate with CLI and SQL outputs (2). Marginal value is unique data versioning (2). Cost benefit is free and open source (2).
Evidence shows: Claim traceability is adequate with docs and tests (2). Cross-source corroboration is partial with test files but no independent verification (1). Fact-inference separation is adequate with docs distinguishing facts and inferences (2).
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- No malicious code or obvious risks found, but publisher identity is unverified; proceed with caution.
- Dependency security lacks vulnerability scanning evidence; consider checking dependencies for vulnerabilities.
- User confirmation mechanism is absent; be cautious with automated operations.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v2.5.0 2.5.0
Release notes excerpt
This is a minor release because it contains backwards incompatible behavioral changes: * It is now possible to commit changes on more than one branch in the same SQL transaction. Previously, such transactions would fail with an error message. * It's also possible to dolt commit to more than one branch via dolt_commit(), but only if the new session variable @dolt_multi_branch_commit is set to a true value. Previously, such procedure calls would fail with an error message. …View on GitHub ↗ -
v2.4.2 2.4.2
Release notes excerpt
Merged PRs dolt * [12025](https://github.com/dolthub/dolt/pull/12025): Fixed foreign keys referencing a renamed index This fixes the issue presented in: * https://github.com/dolthub/doltgresql/issues/3517 This moves the index renaming logic so that it also covers ALTER INDEX instead of only RENAME INDEX. * [12024](https://github.com/dolthub/dolt/pull/12024): Quoted dolt_blame view identifiers with the engine's schema formatter …View on GitHub ↗ -
v2.4.1 2.4.1
Release notes excerpt
Merged PRs dolt * [12016](https://github.com/dolthub/dolt/pull/12016): /{go,integration-tests}: use a more specific cache key Use the local database cache root, remote URL, and effective Git ref as the cache key so databases and custom refs cannot incorrectly share a remote handle. The SQL provider and Git remote factory share key construction, and remote opens and cache lookups share parameter construction. Validated with all eight SQL Git-remote integration tests and targeted remote configuration, factory, and database provider Go tests. Fixes #12011. …View on GitHub ↗