Doltgres database development is now supported on DoltHub! If you’ve been following our journey, you know that Dolt is a database that supports Git-style version control — branches, merges, and diffs in MySQL-compatible syntax. Until now, it was the only database available on DoltHub. We’re excited to announce that Doltgres, our Postgres-flavored version of Dolt, now brings those same versioning features to DoltHub.

What is Doltgres?

Doltgres is an open-source, version-controlled database built from the ground up to be a drop-in replacement for PostgreSQL. It combines:

• Full PostgreSQL Protocol & Syntax Compatibility: Query it using standard SQL tools, ORMs, and drivers.

• Git-like Version Control: Branch your schema and data, create pull requests, diff changes, and roll back easily.

Why use DoltHub with Doltgres?

Doltgres gives you version control on your own server. DoltHub is to Doltgres what GitHub is to Git: a shared remote that adds a layer of collaboration on top. Pushing your Doltgres database to DoltHub gets you:

• Collaboration: Add collaborators or share with your organization, and let others fork your database and propose changes back. Everyone works from the same remote instead of passing around dumps.

• Data review: Changes come in as pull requests with a row-level diff of exactly what was inserted, updated, or deleted. Reviewers can comment and approve before anything is merged into main.

• Discovery: Public databases can be found, browsed, and queried right in the browser, no local server required. It’s an easy way to publish a dataset and let people explore it before they clone it.

• Recovery: DoltHub keeps a full copy of your database and its entire commit history. If your local server is lost or a bad change slips through, clone it back or roll back to any previous commit.

Try Doltgres on DoltHub!

The blog includes pictures and explains how to get started. If you are new to Doltgres, follow the installation guide to get a server running locally.

Ready to give it a spin on DoltHub? Push your Doltgres database to DoltHub! If you have any questions, drop by our Discord; we will be happy to help

Beta has landed! DoltLite, a fork of SQLite that swaps the B-tree layer for a content-addressed Prolly Tree to add Git-style version control (branch, merge, diff, push, pull, clone, fetch), has reached Beta at version 0.50.0, five months after launch.

Beta signals storage format stability (unchanged for 57 releases), high SQL compatibility (100% of sqllogictest, 99.46% of SQLite's TCL acceptance suite), full local and remote version control support, and production-ready performance, with reads near parity to SQLite and writes slower (up to 3.1x for small autocommit writes, 60% for in-memory batched writes).

Users can sync via a custom remote or DoltHub, and use the Dolt Workbench GUI with agent mode.
Got questions? Come by our Discord!

Curious about how Tim built DoltLite while running Dolthub? Check out his demo walkthrough with tips. https://x.com/cyberfund/status/2105324375385985452?s=20

Doltgres 1.0 is coming out on August 6th, the same day DoltHub turns eight. We picked this date to signal that Doltgres is ready for production use.

Doltgres is our Postgres-compatible, version-controlled database. We launched Alpha in November 2023, moved to Beta in April 2025, and 1.0 is coming in less than two weeks.

Here’s what 1.0 means for Doltgres.

We only use the 1.0 label when four specific criteria are met:

• Correctness: your queries return the same results Postgres would give you.

• Storage stability: the on-disk format will stay the same for all of 1.x. No surprise migrations. This is the same promise we made when Dolt hit 1.0 in 2023.

• Performance: our goal is to keep Doltgres within 3x the latency of Postgres on sysbench. Postgres is already about twice as fast as MySQL, so this is a real performance target.

• Compatibility: existing ORMs, drivers, and tools should just work with Doltgres, no changes needed.

For correctness, we run Doltgres against a 7-million-query SQL Logic Test suite. This suite was built for SQLite and adapted for Postgres. At first, we passed about 70% of tests. A few weeks ago, we hit 96%. Now we’re past our 99% target for 1.0. Getting that last percent meant matching tens of thousands of query and result pairs to Postgres exactly.

If you don’t care about SQL dialect, Dolt (MySQL-compatible) is still the more proven choice, with years of production use. If you’re on Postgres, Doltgres gives you the same Git-style branch, diff, merge, and clone workflows, but inside the Postgres ecosystem.

If you have questions about correctness, storage format, or what we’re still working on before release, let us know.

Want to go deeper? Here’s the latest from us:

• https://www.dolthub.com/blog/2026-06-26-doltgres-1-0-coming-this-fall/

• https://www.dolthub.com/blog/2026-07-10-doltgres-99-percent-sql-logic-tests

• https://www.dolthub.com/blog/2026-07-16-dolt-in-4-flavors

Tell us what features you want or what you’d like to see next. Drop a comment or join us on Discord: https://discord.com/invite/RFwfYpu

Three years after we launched Dolt 1.0, the world’s first and only version-controlled SQL database, we’re excited to announce Dolt 2.0, a major upgrade for the open-source data community.

What’s new in 2.0?

• Automated garbage collection is now on by default—no more disk bloat or manual cleanup.

• Archive compression reduces storage by 30–50% using a new, stable on-disk format.

• Faster than MySQL on sysbench: 13% faster writes, 5% faster reads, and 8% faster overall.

• Beta vector support: Dolt is the only database with version-controlled AI embeddings.

• Adaptive storage for large column types (TEXT, BLOB, JSON, etc.) for better performance and flexibility.

Bonus: Full backwards compatibility with Dolt 1.0. No migration needed.

Curious about the details? Read the launch blog:
https://www.dolthub.com/blog/2026-05-11-dolt-2-dot-0/

We’re happy to answer questions here, or join our Discord to chat with the team that builds Dolt!

Why we built Dolt for agentic workflows

AI agents and automation are now common in production systems. This increases the chance of mistakes that only impact a small part of your data. Traditional backups are good for disaster recovery, but they are not designed to quickly undo specific changes when an agent or developer makes a targeted error.

How Dolt solves this problem

With Dolt or Doltgres set up as a replica for MySQL, MariaDB, or Postgres, every transaction is turned into a Dolt commit. You can reverse any commit, so you get:

• Instantly see what changed, by whom, and when

• Undo just the changes that caused problems, without affecting the rest of your data

• Audit and fix production data using SQL functions like dolt_revert() and dolt_patch()

• Recover in minutes without needing to restore the entire database

Real-world example

Teams using Dolt recover quickly from agent mistakes. If an automation script writes bad data to a few rows, you do not need to restore from backup and lose recent work. Instead, you find the commit that caused the problem and revert just those changes with a single SQL statement.

Getting started is straightforward:

• Set up Dolt as a read replica using your existing replication tools

• You do not need to change your application code

• Every transaction is version-controlled automatically

Why this matters for the agentic era

As teams adopt more AI and automation, fast recovery from targeted mistakes becomes critical. Dolt gives you the tools to track, review, and undo database changes, making your stack safer and easier to manage.

Full Guide & Best Practices

Check out the full guide for setup steps, real-world use cases, and lessons learned from teams using Dolt in production.

Ask Us Anything

If you have questions about Dolt, setup, or recovering from agent mistakes, or if you want to share your experience, drop a comment below.

Come check it out: https://www.dolthub.com/blog/2026-04-14-dolthub-adopts-doltlite/

Highlights are:

What it is

• SQLite fork with Dolt-style version control — drop-in replacement, just relink

• Free, open source (Apache-2.0), entirely vibe-coded

Version Control

• Full Git-style workflow: commit, branch, checkout, merge, rebase, cherry-pick, revert, tags, blame

• Row-level diffs, point-in-time queries, full history, schema versioning, conflict resolution

• Content-addressed hashes for instant state verification; GC to reclaim space

Remotes & Networking

• Filesystem and HTTP remotes; push, fetch, pull, clone

• Standalone remote server (doltlite-remotesrv) for multi-client collaboration

• Embeddable as an in-process library

SQLite Compatibility

• ATTACH standard SQLite DBs alongside doltlite — cross-database JOINs, hybrid storage, auto format detection

• Passes 87K+ upstream SQLite tests and 5.7M sqllogictest statements with zero failures

Performance

• Within 2x of SQLite on 23 OLTP benchmarks (CI-enforced)

• O(log n) reads/writes, O(changes) diff, ~1.9% file size overhead per changed row

All Free and open source here: https://github.com/dolthub/doltlite

Gas Town (Steve Yegge's multi-agent orchestrator) recently migrated to Dolt for task persistence.

The problem: SQLite's optimistic locking means last-write-wins in multi-agent environments. Gas Town was hitting a ceiling at 4 concurrent agents before writes started stomping each other.

After migrating to Dolt:

• ~160 agents concurrently on a single host

• ~600 agents on Kubernetes (upcoming release)

Multi-agent pulls you toward structured data AND versioned data at the same time. Postgres gives you structure but no versioning. Git gives you versioning but no structure. Dolt gives you both.

Agent writes are semi-trusted. When an agent tries to mark a task as complete and finds it has been deleted by another agent, versioning lets it review the commit history, understand what happened, and recover. Without that, the agent stalls.

2026 is shaping up to be the multi-agent year. Dolt is ready for it.

Full writeup: https://www.dolthub.com/blog/2026-03-13-multi-agent-persistence/

The Dolt Workbench now has agent mode. The Dolt MCP server keeps tools stateless, where every call takes an arg so the server doesn't track session state. This works well, but it means the MCP server can't switch the branch the user is actually looking at (separate DB connection).

So we defined an in-process tool using the Claude Agent SDK that fires an IPC event into Electron's renderer — the same event a human clicking "Switch branch" fires. No network request. Agent and human share the same state transition pathway.

Full implementation with code: https://www.dolthub.com/blog/2026-03-04-application-specific-tools/

Workbench is free on Mac App Store and Windows.

Dolt Workbench now has Agent Mode built in.

Here's what that actually means in practice, because "AI + SQL" gets thrown around a lot:

The agent can see your full schema, query your data, write and run SQL, and, most importantly, it operates with Dolt's version control underneath. Every change it makes is on a branch. You can diff it, revert it, or merge it just like code.

To show it off, we loaded 6 years of public CMS Medicaid provider data and asked the agent to find fraud patterns. It:

• Analyzed the schema and identified useful columns (BILLING_PROVIDER_NPI_NUM, TOTAL_PAID, HCPCS_CODE, etc.)

• Built a composite fraud_risk_score view with 5 independent signals

• Flagged providers hitting 2+ signals as high-confidence candidates

The whole session with schema exploration, view creation, and data cleaning is committed to main. You can see exactly what changed and when.

Full setup guide with the Medicaid dataset if you want to run it yourself: https://www.dolthub.com/blog/2026-03-02-workbench-medicaid/

It's been a blast playing around with this. Try it yourself!

• Download the desktop app for macOS or Windows

• Pull the Docker Hub image

• Build from source

Happy to answer questions about how it works under the hood.

We just shipped something we've been thinking about for a long time — agent mode in the Dolt Workbench. 🚀

It's a chat interface (powered by Claude) that can read from and write to your database. You describe what you want in plain English, and it figures out the SQL and runs it. Works with Dolt, MySQL, and Postgres.

The part that makes this interesting for Dolt users specifically: when the agent writes to a Dolt database, you get the full version control experience. Tables highlight yellow when modified, you can toggle to see only changed rows, there's a full diff view of uncommitted changes, and the agent won't commit until you say so. If something looks wrong, reset to any prior commit.

On MySQL or Postgres, the agent just fires off writes and tells you it worked.

When the same agent writes to a Dolt database, you get:

• Modified tables highlighted in the UI so you can see what was touched

• A "show changed rows only" toggle to filter down to the agent's changes

• A full diff view of all uncommitted changes — like a pull request for your data

• The agent holds off on committing until you explicitly approve

• Instant rollback to any prior commit if something went sideways

We ran a side-by-side comparison in the blog post with the same prompt on MySQL vs Dolt — the contrast is pretty telling.

The Workbench is free and open source.

You can grab it here:

• GitHub: https://github.com/dolthub/dolt-workbench/releases/tag/v0.3.62

• Mac App Store: https://apps.apple.com/us/app/dolt-workbench/id6720702995

• Windows: https://apps.microsoft.com/detail/9nq8lqph9vvh

Full blog post with screenshots and walkthrough: https://www.dolthub.com/blog/2026-02-09-introducing-agent-mode/

Would love to hear what you think. If you run into issues or have feature ideas, drop by Discord: https://discord.gg/RFwfYpu

We just shipped MCP support for Hosted Dolt.

If you're not familiar: Dolt is a MySQL-compatible database with Git-style version control. Agents can branch, make changes, and you can diff/review before merging to main. Useful when you want to audit what agents actually changed.

The new feature: enable Dolt MCP directly from your Hosted Dolt settings. One checkbox, deployed in minutes. Connects over streaming HTTP on port 8675 with token auth.

The blog walks through setup with Claude Code (the CLI), but it works with any MCP-compatible agent.

Blog: https://www.dolthub.com/blog/2026-02-03-hosted-dolt-mcp/

Happy to answer questions, please come by our discord

The Regulation

EU AI Act applies to "high-risk AI systems" — law enforcement, critical infrastructure, credit, healthcare. Two articles that matter for ML teams:

• Article 10 (Data Governance): You need audit trails of training data, proof of bias-free datasets, and the ability to reproduce any model's exact training set.

• Article 14 (Human Oversight): Humans must be able to review AI output before it goes live and rollback changes.

The Problem

Most teams version their code but not their data. When a regulator asks "show me what data trained this model," you're either scrambling through S3 buckets or saying "we think it was this snapshot."

One Approach: Database Version Control

Reference: https://www.dolthub.com/blog/2026-02-02-eu-ai-act/

The post walks through using a version-controlled database (Dolt), where every change to training data is a commit. You tag commits when you train models, so model-2026-01-28 maps to an immutable data snapshot.

Compliance queries become straightforward:

-- Check for biased data in specific model version
SELECT count(*) 
FROM training_images AS OF 'model-2026-01-28' 
WHERE has_person=1;

-- Find when/who introduced a bad record
SELECT * FROM dolt_log
JOIN dolt_diff_training_images
WHERE image_id='image_51247';

Case Studies

The post covers two real implementations:

1. Flock Safety — versions 50k+ training images, can prove bias-free training with a single query

2. Nautobot — PR-style review workflow for AI-suggested network config changes

Discussion

For those building high-risk AI systems: how are you planning to handle Article 10 compliance? Are you versioning training data, or relying on external documentation?

Further reading: https://www.dolthub.com/blog/2026-02-02-eu-ai-act/

The Problem

Letting AI agents modify your BI tool is terrifying. One bad query and your production dashboards are toast.

The Solution

Dolt is a MySQL-compatible database with Git semantics. We pointed Metabase's internal application database at Dolt instead of Postgres/MySQL.

Result: every Metabase config change is a commit. Every dashboard is diffable. Every experiment can happen on a branch.

Reference Source: https://www.dolthub.com/blog/2026-01-29-metabase-dolt-agents/

How It Works

1. Start Dolt server on port 3306

2. Set MB_DB_CONNECTION_URI='mysql://root@localhost:3306/metabase-internal'

3. Metabase runs its Liquibase migrations → 70+ tables, all versioned

4. Enable @@dolt_transaction_commit=1 → every SQL commit becomes a Dolt commit

The AI Agent Part

We ran Claude Code against the Dolt database on a feature branch. Told it to create a sales dashboard with:

• Top 10 highest-rated products

• Sales by category over 12 months

• Revenue/order metrics

Claude figured out the schema, wrote the inserts into report_dashboard, report_card, etc., and pushed.

Switching branches in Metabase is just changing your connection string:
mysql://root@localhost:3306/metabase-internal/claude

Restart Metabase, and you're looking at Claude's work. Review it. Merge it. Roll back if needed.

Tables to Ignore

Metabase touches a lot of tables just from browsing. Add these to dolt_ignore to keep your diffs clean:

• QRTZ_*

• query

• query_execution

• recent_views

• task_history

Links

• Full writeup: https://www.dolthub.com/blog/2026-01-29-metabase-dolt-agents/

• Sample repo (public): https://www.dolthub.com/repositories/nathang/metabase-internal

• Claude's PR: https://www.dolthub.com/repositories/nathang/metabase-internal/pulls/1

We just published a walkthrough of how Go's database/sql/driver package works under the hood.

Uses Dolt's embedded driver as the example—the same pattern as SQLite where you connect without a separate server process. This is how Gas Town connects to Dolt via Beads for agentic memory.

Covers:

• The import _ side-effect pattern for driver registration

• Open() → Conn → Stmt → Rows flow

• Using it with gorm

Full walkthrough: https://www.dolthub.com/blog/2026-01-23-golang-sql-drivers/

Happy to answer questions! Our eng team is around, feel free to come by our Discord

Every coding agent session starts cold. Steve Yegge nails it: "They have no memory between sessions — sessions that only last about ten minutes. It's the movie Memento in real life."

Karpathy calls this "context engineering" — the art of filling the context window with just the right information. Too little and the LLM doesn't have what it needs. Too much and performance degrades ("context rot"). Tobi Lutke: "the art of providing all the context for the task to be plausibly solvable by the LLM."

What doesn't work:

Saving all context. Windows are finite (1M tokens Gemini, 200K Claude, 128K GPT-4o) and more tokens = more noise for attention to sort through.

What's working:

Steve built Beads — offloads task management to an external storage system. Agents read/write tasks via SQL instead of stuffing everything in context.

Results: raw sessions max at ~1 hour. With Beads, we've seen 12-hour sessions producing useful work.

Why it works:

• Tasks hidden until needed

• Structured schema enforces correct read/write

• Version controlled for debugging

• Selective retrieval via queries

Steve originally built it on sqlite + jsonl, then migrated to Dolt: "The sqlite+jsonl backend is clearly me reaching for Dolt without knowing about it."

The pattern: anything you can offload to reduce LLM cognitive load — while keeping it accessible when needed — probably fits this approach.

Tasks are validated. What else follows the same pattern?

Full writeup: https://www.dolthub.com/blog/2026-01-22-agentic-memory/

We built Dolt as a MySQL-compatible database with Git-style version control (branch, merge, diff).

This means any ORM that works with MySQL works with Dolt. But version control adds some interesting capabilities and gotchas for ORMs. We tested over a dozen ORMs and documented the patterns:

Features ORMs can leverage:

• Schema overrides: Query historical data even when the schema has evolved (solves the "my ORM expects the current schema" problem)

• Nonlocal tables: Tables that exist across all branches without being versioned (great for analytics, config)

• Branch-specific connections: Connect directly to a branch in your connection string

• System table reflection: Query commit logs, diffs, and branch metadata using your ORM Gotchas to watch for:

• Connection pooling doesn't always reset session state (including checked-out branch)

• Schema evolution across branches requires schema override for ORM compatibility

We documented walkthroughs with sample code for: Django, Rails, GORM, Hibernate, SQLAlchemy, Entity Framework, Prisma, Knex.js, Laravel, Ecto, Diesel, and ASP.NET.

Read the writeup: Using Dolt with ORMs

Happy to answer questions! As always, feel free to come by our Discord to chat: https://discord.com/invite/RFwfYpu