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

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.

> 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

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.