The simple way to fork a sqlite db is just to copy it, but if that is too slow you could use it with a copy on write filesystem, either something native, a FUSE filesystem, or build a sqlite VFS.
That would probably be faster to build, faster to run, and easier to validate.
Here's an in-memory one I made (pretty useful for unit tests): https://github.com/ncruces/go-sqlite3/tree/main/vfs/mvcc
The problem DoltLite solves is merging, not forking.
SQLite recommends against doing that [1] while a transaction is active, because the copy might have some pre/post data in it which could potentially cause corruption. Presumably this isn't an issue with copy-on-write filesystems assuming they copy atomically, but I probably still wouldn't do it, instead use the backup API or VACUUM INTO (if nothing else, because VACUUM INTO will also obviously VACUUM the copy).
If you're not attached/writing to it, then of course it's fine.
[1]: https://www.sqlite.org/howtocorrupt.html#_backup_or_restore_...
No? Where are you getting those figures? It feels like you may have pulled that from the 125 and 400 us numbers?
> The simple way to fork a sqlite db is just to copy it, but if that is too slow you could use it with a copy on write filesystem, either something native, a FUSE filesystem, or build a sqlite VFS.
That wouldn’t really solve what dolt does though.
> and it's level of testing and validation will be nothing like sqlite.
They’re using the other dolt tests as well as the SQLite tests. Nothing will hit the level of real world testing SQLite does.
https://www.dolthub.com/blog/2026-06-08-how-fast-is-doltlite...
[0] - https://www.dolthub.com/blog/2019-10-14-dolt-a-simple-exampl...
But worse.
> Gas Town is for “write-only code”, … If you adopt Gas Town, you will lose the speed benefit of multiple agents if you read the code it produces. The first time you stare at an 8,500 line Git diff and try and parse what happened, you’ve lost. Go back to a single Claude Code session. Gas Town isn’t for you.
So none of the code has even been read by the author, it’s purposely overly verbose. “Touched by LLMs” seems to downplay just how vibe coded this is. I won’t use this database for anything.
From the article, at the end of the second paragraph:
> Could a team of agents pull it off? It only took about 2,000 pull requests but DoltLite going Beta proves a team of agents certainly could.
The first PR was merged March 17th.
"vibe coded" seems pretty fitting
Kudos to the team behind SQLite. These people built smt absolutely amazing!
FWIW, search [and research] about offline-first apps. Lots of gems in this niche!
https://www.dolthub.com/blog/2024-10-15-dolt-use-cases/
For DoltLite, the big use case is embedded local-first development. It's a DB you can write to locally offline, then sync to a remote server when you have connectivity. Crucially, this works in both directions, and tolerates writes from multiple offline clients by merging their changes together.
A VCS is useful for code, because plaintext lacks a version feature. This problem does not exist for databases, because you design the structure yourself.
This specific community has been a Schelling point for some of the worst engineering practices I've ever seen and a desire to abstract away all details of code to LLM personas like the "Refinery" and "Deacon"
But the feedback loop was automated and accelerated. Instead of 1000 loops spread over 20 years, it had 1000 loops over a few months.
Calling it "vibe coded" just shows something about you, not the project. It is not production ready yet, but that is not for fast ai dev or for technical reasons. It needs independent reviews, independent verification, and reputation.
So when you say battle tested earlier, and then not production ready later - which one is it?
https://www.dolthub.com/blog/2026-04-27-why-doltlite/
In general, branch and merge seem to be required primitives for agentic writes. Would you let a coding agent change your code if it wasn't in Git? We think the same will apply to databases.
This is not primarily for backups and has been part of ml and ds work for a while. And more, but that’s where I hit it.
> This problem does not exist for databases, because you design the structure yourself.
It is entirely possible to solve a lot of this in a more generic way, so that you don’t have to solve it each time. That’s what dolt is about.
Here’s a blog post from a few years ago with some use cases from actual users
But anyway I assume that random name green account above is just a pro-vibe coding bot.
Grouping it all under “vibe coded” loses precision. Sure, it uses AI, but differently from other projects and with different implications.
Most successful agent-coded projects have a few essential features that it's worth calling out: 1) The human driving it has real domain expertise; 2) There's an oracle for correctness; 3) The agent has a real-world example to copy, adapt, or translate.
This project had all these elements. The human driving the agent understood the technical and product decisions that make a version-controlled database work, because he's been doing that for 8 years. The project uses the existing 5.7M query test suite for SQLite3 as its oracle, as well as adapted versions of Dolt's extensive test suite to verify the version-control features that SQLite has no tests for. And the agent had a human-written implementation of the core product (Dolt) to crib from.
All of this is to say: yes, agents wrote this code, but if you or another randomly chosen software engineer sat down and tried to duplicate this result you wouldn't succeed. You wouldn't know what the agent had gotten wrong at every step of development, or even what questions to ask to find out where the errors might be. Despite the existence of a correctness oracle, the agent on its own cannot iterate to 100% correctness without a domain expert steering it. And that expert also has to have an extensive understanding of the existing code base that's being copied. You can't just say "Claude, implement version control in SQLite3, make no mistakes", it's not going to work.
Sure the benchmark does not measure a real world application, but I never claimed it was.
Do you have a better benchmark to share?
I thought I was being charitable by using a benchmark published by the database's own authors.