This has been shared without context but I guess the SQLite team is starting to modularize the btree code in order to facilitate work like SQLightning: <a href="https://github.com/LMDB/sqlightning" rel="nofollow">https://github.com/LMDB/sqlightning</a><p>At the time SQLightning greatly improved SQLite performance but due to LMDB's requirement to have keys fit in 2/3 of a page it wasn't really useful as a general purpose replacement of SQLite's internal b-tree implementation.<p>EDIT: It looks like SQLightning got adopted and has been worked on by the SQLite team under the name LumoSQL. Here's the project's readme: <a href="https://lumosql.org/src/lumosql/doc/trunk/README.md" rel="nofollow">https://lumosql.org/src/lumosql/doc/trunk/README.md</a> which contains at the end "A Brief History of LumoSQL"
A bit off-topic, but SQLite continues to impress me. This year, we've added a simple form builder to our product which allows creators to quickly gather feedback/input from their audiences. Basically each form has it's own small sqlite database as a datastore and a json file for the form definition (field styling/constraints, etc). It's 'low tech', but performs great. Not having an additional service running also means having one less thing to maintain.
OK I love SQLite but there has been a long-standing misconception, or issue, that I'd like to get clarification on: Is using SQLite from multiple processes safe?<p>For a long while, either SQLite itself or the Python bindings weren't safe for concurrent access, is this still the case? Can I use SQLite for my Django app? With the backup system on the Tailscale post yesterday, the operational burden is much much lower than Postgres for many use cases.