I'd say the most interesting thing on that site is the Not-Forking idea[1].<p>1. <a href="https://lumosql.org/src/not-forking/doc/trunk/README.md" rel="nofollow">https://lumosql.org/src/not-forking/doc/trunk/README.md</a>
I feel like this best explains what added benefits LumoSQL tries to add:<p>> LumoSQL is a derivative of SQLite, the most-used software in the world. Our focus is on privacy, at-rest encryption, reproducibility and the things needed to support these goals. [...]<p><a href="https://lumosql.org/src/lumosql/file?name=doc/project-announce-phase2.md&ci=trunk" rel="nofollow">https://lumosql.org/src/lumosql/file?name=doc/project-announ...</a><p>I'm unsure what Phase 1 was about, or if there is a planned Phase 3, but seems to outline what they're currently aiming for at least.
> LumoSQL exists to demonstrate changes to SQLite that might be useful, but which SQLite probably cannot consider for many years because of SQLite's unique position of being used by a majority of the world's population.<p>> SQLite is used by thousands of software projects, just three being Google's Android, Mozilla's Firefox and Apple's iOS which between them have billions of users. That is a main reason why SQLite is so careful and conservative with all changes.<p>That's a great perspective. How well does the SQLite team work with them? How well does it work in production, especially if you need SQLite compatibility? And
How does LumoSQL deal with locking? If I proposed Wildcat as a storage engine which is lockless. Can LumoSQL be optimized for atomicy and multi writer? C shared library too if you're curious <a href="https://wildcatdb.com" rel="nofollow">https://wildcatdb.com</a>
Possibly the wrong place to ask this, but:<p>I've played with SQLite when it was still available in-browser, and I felt that was on the brink of being a game-changer. If it was still supported in-browser and we had replication <i>from</i> the browser, peer-to-peer, I think we'd be living in a much more useful world. It's a lovely tech, but I never built anything serious around it. At this point, as a front-end web technology that seems to be gone. I know I could conceivably use it to back a NodeJS server, keep all the data in memory and local files, but I don't see a great use case for that. I do lots of small projects that <i>could</i> use SQLite, but I usually scaffold them around a single shot Mysql DB for testing, which is easy to spin up and easy to detach from any given back-end instance. So I'm not sure what I'd gain by trying to make a tiny databse on the back-end live in Sqlite files. I'm <i>totally enchanted</i> by stuff like Litestream, and I'm actually dying to find a reason to try it. But every good use case for Sqlite that I could think of sort of died when it stopped being a viable client-side store.<p>TL;DR, what are people using SQLite for? What's the advantage over spinning up a tiny MySQL instance in a cloud somewhere, where you don't have to deal with managing replication and failover by yourself?
SQLite itself is open source, but the last time I checked, its test suite remains proprietary.<p>How does a "fork" like this be tested if everything stays working and compatible to upstream after the change?
AFAIR, LMDB is very buggy. There was one person who showed that and maintained fork of LMDB with many bugs fixed, but he is very opinionated and think that world outside Russia is "evil" and forbid to use his fork for evil...<p>Oh, license was changed to Apache 2.0! But still github account has note which equals Hitler to Soros...<p>Why should SQLite backend be replaced with LMDB?<p>UPD: Ooops, LMDB was forked a long time ago, so, maybe, LMDB can be fixed already!