From a real test run
Measured numbers
Speed and correctness from a real run on one machine. Not a production benchmark.
The run
A test loads thousands of memories across several accounts, runs hundreds of searches, tries to read across accounts, checks every log chain and runs all 33 checks. The table below is read straight from that run's report; no number is typed in by hand. Raw report: /aether33/stress.json.
Report
| Measured at | 2026-11-02T15:40:06Z |
|---|---|
| Host | Linux-7.0.0-38-generic-x86_64-with-glibc2.43 · Python 3.14.4 · 8 CPUs |
| Workload | 2,000 documents · 4 tenants · 500 queries · seed 7 |
| Throughput | 145.6 writes/s (write phase, 13.741 s) · 31.428 s total including the concurrency phase |
| Database | 2,224,128 bytes on disk |
| Concurrency | 8 threads · 800 writes · 0 errors · p50 62.053 ms / p99 205.313 ms · 8/8 chains ok · 0 isolation failures of 8 SQLite is single-writer; concurrent tenants serialize on the write lock. Higher latency here is expected, not a defect. Zero errors and intact chains are the pass condition. |
| Chains | stress_t0_7: 500 entries, ok; stress_t1_7: 500 entries, ok; stress_t2_7: 500 entries, ok; stress_t3_7: 500 entries, ok |
| Determinism | 0 ordering mismatches across repeated identical queries |
Measured on this host, single process, one SQLite file in WAL mode, no network and no model. The concurrency phase runs 8 threads against that same file; SQLite is single-writer, so higher latency there is expected. Not a production benchmark and not a multi-host test.
How to read it
Times are in milliseconds on a shared server. Several writers at once slow down because one database file accepts one writer at a time. That is a real limit, stated rather than hidden.
grants_authority: false.
No third-party audit has been performed. Limits ·
FAQ · what is live now