smartbotic-database/service/spike/v2_lmdb

Phase C build-vs-buy spike — LMDB candidate

Throwaway prototype that backs document storage with LMDB. The goal is to answer the questions the Phase C plan poses for the build-vs-buy spike:

1. Write throughput ceiling under single-writer LMDB.
2. RSS behaviour as dataset grows beyond physical RAM (the headline v2.0 goal — bounded RSS regardless of dataset size).
3. Cold-boot time on a populated DB.
4. Read throughput / point-lookup latency.
5. On-disk size per Zoe-shape doc.

Scope (deliberately tiny)

• Document body uses to_json_text from service/src/doc_binary.cpp as the on-disk encoding (yyjson-write of a mut_doc). Reading goes through the existing Phase A bridge (parse_to_nlohmann) plus the Phase B encode to reconstruct the Doc. Real Phase C work would drop the round-trip through nlohmann and serialise yyjson_doc bytes directly, but that's beyond the spike.
• Single environment, single DB. No collections, no indexes, no history, no replication. ID → bytes.
• No concurrency yet — single-threaded inserts then single-threaded reads. Concurrent reads can be added if LMDB's write ceiling looks promising.

Build

Standalone from the main build; nothing in this directory is part of the production smartbotic-database binary. Configure into a sibling build/ directory:

cd /data/smartbotic-database/service/spike/v2_lmdb
cmake -B build -G Ninja
cmake --build build
./build/bench_lmdb_storage --docs 100000 --map-mb 4096

What the spike does NOT prove

• That LMDB is the right choice for production. Even if numbers look good, the single-writer model and the schema-on-top burden need separate evaluation.
• That homegrown pages would lose. The plan calls for an LMDB-first measurement so the much heavier homegrown option only gets built if LMDB falls short of write-throughput requirements.