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_...

> 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.

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...

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

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.

You’d have to do the relevant R&D and maintain the product.

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

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.

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.

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).

After about three weeks I hand drove three agents in parallel for 8-10 hours/day. There is very little automation.