Fix lower bound of SQLite version in not-fork.d/sqlite3/benchmark/versions and not-fork.d/lmdb/benchmark/versions. It was 3.36.0 but there has been a little drift in vdbe.c . Temporarily bumped it up to 3.43.0 so that eg make test-sql works first time. Needs some testing and simple fixes.

We don't produce a good version number for LumoSQL except in the VCS and documentation, plus we inconsistently append to the version hash, eg: 3.53.2++lmdbv1_debug-on has version "3.53.2 2026-06-03 19:12:13 d6e03d8c777cfa2d35e3b60d8ec3e0187f3e9f99d8e2ee9cac695fd6fcdfalt1" While 3.53.2+lmdb-0.9.35 has version "3.53.2 2026-06-03 19:12:13 d6e03d8c777cfa2d35e3b60d8ec3e0187f3e9f99d8e2ee9cac695fd6fcdfalt1lmdb". We should probably #define LUMOSQL_VERSION, and add a --lumosql-version parameter at least. What else? This is important including for: benchmark database (what LumoSQL version gave this result?); not-forking; and very likely for putting in the header of the database in a similar way to SQLite, assuming we can reconcile what to do on different backends including standard SQLite. This will become a problem when we are consolidating benchmark data from many people. We have done some research on SQLite Meta Slots which could potentially hold some detailed version information, and in the test suite we do some probing for capabilities in a LumoSQL binary, and that is potentially how some version reporting could be done.

Introduce a solution for AVL ephemeral tree spilling, as discussed in examples/fossil/importing-massive-trees-to-fossil-lumosql.md and the comment for bd8a225546 . This would mean LUMO_NOEPH would no longer be a developer-only test tool. We don't need this for ordinary workloads, so it seems.

Stress test the AVL ephemeral tree code. We do currently test it but not to extremes. It's small but complicated and brand-new, and critical.

We expose rowsums via the lumo_rowsum function. This may be sufficient for doing column comparisons, but since we don't have users yet that isn't clear. Rowsums have a cost, but for some workloads they are much faster where column comparisons are done. Perhaps rowsums should be exposed in higher-level SQL, so we can say "store the rowsums for this table" and then later "list only the rows that have changed" which will involve integer comparisons no matter how large and complicated the row contents might be.

We vendor the portable BLAKE3 algorithm. The non-portable SIMD version of BLAKE3 is much faster, taking advantage of CPU features on x86_64, ARM and WASM. On the other hand, we have profiled the rowsum slowdown and it is not due to hashing at all, at least on hardware that isn't tiny and embedded.

There is extensive discussion of Attribute-Based Encryption (ABE) in doc/design-rbac.md . This would drop in to the mechanism we know works reliably for rowsums, and is the subject of the draft RFC. This hasn't been updated for the 2026 project reboot but the scholarship over the last 4 years would seem to still support the concept.

not-fork upstream.conf version_filter cannot cleanly express "exclude the 1.x line" against the LMDB recipe. The current < 1.0-alpha in upstream.conf is a hack exploiting the convention that pre-release suffixes sort below the bare version: 1.0-alpha is the lowest known pre-release token, so comparing against it excludes everything else including any 1.x releases. This is a not-fork bug but not urgent for LumoSQL now we have this hack in place.

The LMDBv1.0 encryption implementation is very basic, including lacking any interesting ciphers.

It's time to carefully review the versions in the benchmarking files under not-fork/ . These are the defaults and override what is specified on the make commandline.

The build resolves latest to 3.53.2 even when you pass SQLITE_VERSIONS=3.53.1 (3.53.1 maps forward), which may surprise someone expecting an exact-version build. This is a feature of the build system and the not-forking definition file where it is set to interpret these parameters as being the same as 'latest'. This needs thinking about although its not really urgent.

when OPTION_LMDBV1_ENCRYPT=on is set, the build system emits two targets instead of one. The target-name logic acts on the lmdbv1_encrypt option whether lmdbv1 is present or not, so it generates a spurious encryption target in parallel with the real one, eg 3.53.2++lmdbv1_encrypt-on (note the double '+', which is an empty version field between the '+'s.) This is a correctly working binary we don't want and didn't ask for, with a dud name.

LMDB-backed Fossil can't clone from a local file:// path (is this still true, post single-file LMDB in Lumo?) This is not a LumoSQL bug, but for the moment we are carrying the tiny number of Fossil patches in a markdown file so make a note here...

Need to do build/bench on ARM. This may involve a small amount of porting.

The global config (~/.config/fossil.db, or ~/.fossil / ~/_fossil depending on platform and $HOME layout) needs to be in the same format LumoSQL is compiled to support, either native Fossil (a single SQLite file) or LumoSQL Fossil (an LMDB single file). Whenever you alternate between the two binaries, for example for testing, the new binary inherits a config it can't read and fails with SQLITE_CANTOPEN or sometimes just "unknown error". Clear it with rm -rf ~/.config/fossil.db ~/.config/fossil.db/ ~/.fossil ~/.fossil/ before switching binaries. You can also choose to isolate the global config in its own per-test directory structure to avoid this, but it is still an annoying problem for LumoSQL experimenters and developers.

As part of profiling, focus on the LMDB property that readers never block writers, and writers never block readers. Concurrency testing of LumoSQL suggests this property could be exposed more, by considering the design of the LMDB backend shim. We need more concurrency testing anyway. The test-sql target makes a good start.

We vendor the reference implementation of SipHash with a fixed, public MAC key, 0xfeedface. Need to support private MAC keys.

Replace the LMDBv1 backup code which currently has v0.9 stuff with a stub and appropriate error. LMDBv1 does incremental backup and that's what should be used.

examples/fossil/Makefile has a check-lumosql stanza which is specific to LMDB. We have a BACKEND_SPEC variable intended for a backend-agnostic build but the Makefile is not agnostic yet. It could make sense even at this point for rowsum with native SQLite, and certainly for future backends with other btree replacements than LMDB.