So the main feature of this project is that it's easy to fork a database, however it's 1.2x to 4x slower than sqlite, and it's level of testing and validation will be nothing like sqlite.
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.
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.
Dunno if I'd have directly attributed the writing to LLMs had I not read this, but I wouldn't have opened the link otherwise. Holy crap, that reads just like the documentation / explainers that I have Claude write for future agents or to remind me what I had it do in the future.
Ah yes so the 4x slower isn’t really a real world case and you’d have to explicitly measure yours - it’s not a fixed slowdown but depends on table size - and it’s for doing many many single inserts in a row, which you’d be batching either way.
> The simple way to fork a sqlite db is just to copy it
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.
Dolt has been around for 7 years[0]. Doltlite, like most software nowadays, has been touched by LLMs, but dismissing this project as "vibe coded" seems harsh
If going through a strongly designed process with quality gates is vibe coding, I guess so. I thought the term was reserved fir “claude, make this happen” style development and the term for the more professional approach was “agentic development”, though this seems to be another layer higher.
Grouping it all under “vibe coded” loses precision. Sure, it uses AI, but differently from other projects and with different implications.
> 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.
Look at dev process (i did), this think is "tested to hell" and "battle tested".
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.
That's selling it short. You could deploy something to production in minutes. Battle tested implies it's been not only deployed, but heavily used in all kinds of scenarios, and in the case of sqlite, probably by millions of different apps.
But anyway I assume that random name green account above is just a pro-vibe coding bot.
Battle tested and tested to hell, maybe yes. But still horrible insecure architecture, with read-only access being able to write. And totally insecure full text search. https://github.com/rurban/hardsqlite
Psyched to see this! I've been working on my own similar thing that sucks and I don't want to - I want to write a local first music app that syncs across all my devices. This might get me there!
I let agents do their things but I would not trust them with my data without extensive validation. A database efforts main product is not exotic data structures but validation.
One of the reasons SQLite was mostly stable over the years was it sand-boxed its closed developer environment, and clearly defined the project scope. While controversial, they did not have to deal with common accountability issues associated with screening anonymous malicious and or incompetent clown PR. =3
There are filesystems (ZFS and btrfs) with snapshots and this feature can be used to version-control things. They both do copy-on-write and this is pretty close to what content-addressable storage would give you in terms of compression.
For DoltLite in particular, push/pull/clone/fetch are an elegant solution to the local-first sync problem. You can use data conflicts instead of CRDTs.
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.
If you want to take a version from a database, it's usually for backup. If you want different versions in your data, you put that IN the database. Manually merging different database versions does not sound too surprising.
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.
> If you want to take a version from a database, it's usually for backup. If you want different versions in your data, you put that IN the database. Manually merging different database versions does not sound too surprising.
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
You use it to write version-controlled applications, so that your structured table data gets the same collaboration and auditing benefits that your source code enjoys. This is a couple years of out date but should give you an idea for how it's being used in the real world.
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.
Everything touching this ecosystem (Gas Town, Dolt, Beads) seems like the absolute nadir of vibecoded slop
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 post 2020 HN contains 70% AI related posts on the front page such that the moment it is revealed that something is connected to AI, the excitement seems to falter (understandably so).
The biggest limitation I see is the absence of a Go client. I know this opens a can of worms, but using ncruces/wasm2go, or just coordinating with ncruces/go-sqlite3 might work.
So the main feature of this project is that it's easy to fork a database, however it's 1.2x to 4x slower than sqlite, and it's level of testing and validation will be nothing like sqlite.
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.
> however it's 1.2x to 4x slower than sqlite
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.
> Where are you getting those figures?
https://www.dolthub.com/blog/2026-06-08-how-fast-is-doltlite...
God that had a lot of llm'isms. Couldnt get through it with all the repeats and info bloat.
Dunno if I'd have directly attributed the writing to LLMs had I not read this, but I wouldn't have opened the link otherwise. Holy crap, that reads just like the documentation / explainers that I have Claude write for future agents or to remind me what I had it do in the future.
Ah yes so the 4x slower isn’t really a real world case and you’d have to explicitly measure yours - it’s not a fixed slowdown but depends on table size - and it’s for doing many many single inserts in a row, which you’d be batching either way.
That's probably why they gave a range in their original comment.
It's easy to do a VFS that handles instant forking (snapshots).
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.
> The simple way to fork a sqlite db is just to copy it
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_...
if you don't trust something to survive an atomic filesystem snapshot, why would you trust it to survive sudden power loss?
Why would I trust my data to a vibe coded database, over a battle tested, tested to hell and back one?
Dolt has been around for 7 years[0]. Doltlite, like most software nowadays, has been touched by LLMs, but dismissing this project as "vibe coded" seems harsh
[0] - https://www.dolthub.com/blog/2019-10-14-dolt-a-simple-exampl...
> Doltlite, like most software nowadays, has been touched by LLMs, but dismissing this project as "vibe coded" seems harsh
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
If going through a strongly designed process with quality gates is vibe coding, I guess so. I thought the term was reserved fir “claude, make this happen” style development and the term for the more professional approach was “agentic development”, though this seems to be another layer higher.
Grouping it all under “vibe coded” loses precision. Sure, it uses AI, but differently from other projects and with different implications.
Agentic development still requires human review and human ownership of PRs. This is vibe coded. Seems precise to me.
It is vibe coded.
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.
Look at dev process (i did), this think is "tested to hell" and "battle tested".
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.
Battle tested means deployed in production.
So when you say battle tested earlier, and then not production ready later - which one is it?
That's selling it short. You could deploy something to production in minutes. Battle tested implies it's been not only deployed, but heavily used in all kinds of scenarios, and in the case of sqlite, probably by millions of different apps.
But anyway I assume that random name green account above is just a pro-vibe coding bot.
It’s ridiculous how common the bots are becoming, then again Sam’s put a lot of money on the line so can’t be having bad vibes.
This, from a 1 day old throwaway account, tells a lot.
I don't trust AI testing. An automated loop == zero testing in my book.
Battle tested and tested to hell, maybe yes. But still horrible insecure architecture, with read-only access being able to write. And totally insecure full text search. https://github.com/rurban/hardsqlite
Would be good, but why not to vibe code this database myself if I had a problem with my current database?
You’d have to do the relevant R&D and maintain the product.
"But Claude does that for me"
Did I read that correctly that there’s no WAL?
Psyched to see this! I've been working on my own similar thing that sucks and I don't want to - I want to write a local first music app that syncs across all my devices. This might get me there!
I let agents do their things but I would not trust them with my data without extensive validation. A database efforts main product is not exotic data structures but validation.
One of the reasons SQLite was mostly stable over the years was it sand-boxed its closed developer environment, and clearly defined the project scope. While controversial, they did not have to deal with common accountability issues associated with screening anonymous malicious and or incompetent clown PR. =3
https://www.youtube.com/watch?v=T4Upf_B9RLQ
I don't understand why you would want this.
A version controlled db? Have a look at dolts main page then, it’s been around for some time - this is just adding an embedded version.
I read it, and i think i understand even less than when i started.
They’re probably a VC backed product in search of a solution.
Version controlled data is a legitimate solution to actual problems.
Care to name them?
There are filesystems (ZFS and btrfs) with snapshots and this feature can be used to version-control things. They both do copy-on-write and this is pretty close to what content-addressable storage would give you in terms of compression.
With merging updates between branches?
Physical or semantic merging?
What problems does a version controlled database solves that is not solved by proper table auditing ?
not having to implement proper table auditing?
For DoltLite in particular, push/pull/clone/fetch are an elegant solution to the local-first sync problem. You can use data conflicts instead of CRDTs.
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.
If you want to take a version from a database, it's usually for backup. If you want different versions in your data, you put that IN the database. Manually merging different database versions does not sound too surprising.
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.
> If you want to take a version from a database, it's usually for backup. If you want different versions in your data, you put that IN the database. Manually merging different database versions does not sound too surprising.
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
https://www.dolthub.com/blog/2024-10-15-dolt-use-cases/
You use it to write version-controlled applications, so that your structured table data gets the same collaboration and auditing benefits that your source code enjoys. This is a couple years of out date but should give you an idea for how it's being used in the real world.
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.
Everything touching this ecosystem (Gas Town, Dolt, Beads) seems like the absolute nadir of vibecoded slop
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"
Pre 2020 HN reading this would be stoked.
But post 2020 HN contains 70% AI related posts on the front page such that the moment it is revealed that something is connected to AI, the excitement seems to falter (understandably so).
I'm a little more interested how they automated the process to such a degree. How do they do it? Subagents?
After about three weeks I hand drove three agents in parallel for 8-10 hours/day. There is very little automation.
The biggest limitation I see is the absence of a Go client. I know this opens a can of worms, but using ncruces/wasm2go, or just coordinating with ncruces/go-sqlite3 might work.