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.<p>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.<p>That would probably be faster to build, faster to run, and easier to validate.
Would be good, but why not to vibe code this database myself if I had a problem with my current database?
Why would I trust my data to a vibe coded database, over a battle tested, tested to hell and back one?
I don't understand why you would want this.
Did I read that correctly that there’s no WAL?
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<p><a href="https://www.youtube.com/watch?v=T4Upf_B9RLQ" rel="nofollow">https://www.youtube.com/watch?v=T4Upf_B9RLQ</a>