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.

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.