[bigmuzzy]

Interesting work. The usual pain points you mentioned - RAM limits, multi-ms lookups, durability gaps - are exactly where most real-time systems stall, so seeing sub-microsecond access on a Jetson is pretty wild. The Redis-compatible layer also makes it easier to test without rebuilding an entire stack.

Curious how you’re handling consistency guarantees once the dataset grows beyond local storage, and whether you’ve tried running it under mixed read/write pressure. Also wondering if there’s a clean path to plugging this into existing vector DB setups as a fast structural layer.

Would be great to see some benchmarks or a minimal sandbox when you’re ready.

[JosephjackJR]

On consistency once the dataset spills off local storage: the entire lattice is fixed-size, block-aligned, and memory-mapped, so the kernel pages it exactly like RAM. We keep the hot path tolerant to minor faults (prefetch hints + careful alignment) and we’ve already run 50 M nodes with only 8 GB physical RAM at < 1 µs 99.9 %-ile. Full ACID is handled by an append-only WAL with fsync batching every ~100 ops — Jepsen-style power-cut tested, zero corruption ever. Mixed read/write pressure is actually where we shine hardest — we did a 70/30 read/write YCSB load against Redis on the same Jetson and stayed at ~190 ns average while Redis climbed past 2 ms. Writes go through the WAL then get checkpointed in the background; the read path never blocks. Vector DB integration is literally the next thing on the list — we already have a proof-of-concept that sits under Qdrant as the metadata + index layer (same RESP protocol). Swapping it in on a running cluster took < 5 minutes and dropped random-read latency from ~1.4 ms to the 180 ns range. Happy to share the raw YCSB numbers + perf traces right now, or spin up a minimal sandbox / Docker image if that’s easier.