Memory & disk footprint (Beta)
How much machine does Aito need? On a 10M-row linked-invoice database, the v2 engine holds its working set in 597 MB of JVM heap and 3,258 MB on disk — roughly 3.8× less heap and 2.3× less disk than the v1 engine on the identical state.
That heap number is the one that decides how many tenants fit on a box, so it is the number this page is built around.
The measurement
Both engines were pointed at the same optimized 10M-row state, same corpus, same build, each given a 4 GB heap:
| Footprint | v2 (rep2) | v1 (rep1) | v1 ÷ v2 |
|---|---|---|---|
| JVM heap, after GC | 597 MB | 2,276 MB | 3.8× |
| Memory-mapped | 3,288 MB | 7,617 MB | 2.3× |
| On disk | 3,258 MB | 7,617 MB | 2.3× |
| Off-heap (manually managed) | 157 MB | 151 MB | ~1× |
Provenance. booktest InvoicePerf mem-optimized-10M-rep2 (v2) and
mem-optimized-10M (v1) · same corpus, same optimized state, same build · heap
is the live figure after a forced collection, not the JVM's reserved size ·
single dev machine, hardware unspecified. Every cell is a build-time metric
token resolved from those committed snapshots — nothing here is hand-typed.
Why the heap stays flat
The off-heap row is the tell. Off-heap is near-identical between the engines because it is a fixed working area rather than a per-row structure — so it does not move with the corpus. Heap, mapped and disk all do. That is the shape you would predict from the design, and it is what makes the heap figure a property of the architecture rather than a lucky measurement:
- Memory-mapped, zero-allocation reads — a lookup reads straight out of the mapped column file, not a heap-materialized structure. The operating system's page cache, not the JVM heap, holds the dataset.
- Compact on disk — a binary columnar format with adaptive byte widths, so the linkage and column layout stay smaller than a naïve fixed-width layout. Mapped and on-disk track each other because the mapped set is essentially the state's own files.
- Cheaper to build — rebuilding a table's optimized state streams through the columnar writer rather than materializing the whole table on the heap.
Put together: v2 keeps the dataset in mapped column files and reserves the heap for query-sized aggregates, so the heap does not grow with the corpus the way a row-oriented engine's does.
What this does not yet say
It is one scale, not a curve. The table above is measured at 10M rows only. The claim that heap stays flat as the corpus grows rests on the mechanism plus this single point — not on a measured slope. A footprint ladder across 1k / 10k / 100k / 1M / 10M for both engines is the obvious next measurement, and until it exists, read the 3.8× as "the gap at 10M" rather than "the gap at any size."
It is the read path. These figures are a server answering queries from an optimized state. Peak memory during ingest and optimize is a different measurement with a different profile, and is not on this page.
Hardware is unspecified. Single dev machine. The ratio between the two columns is the durable signal; the absolute megabytes depend on the box.
A note on this section's history, kept deliberately. Earlier drafts carried "~2.6× smaller / ~6× less memory" ratios that were not backed by a committed measurement — they traced to a since-removed seed file and a blog draft — and were pulled rather than published as if generated. The table above is the replacement, and it is worth noting the hand-typed pair was wrong in both directions: the measured ratios are ~3.8× on heap and ~2.3× on disk.
Related
- Query, predict & write speed — the latency and throughput side of the same 10M state
- How big can my database get? — the accuracy and latency ladder from 1k to 10M rows
- Clusters & scaling · Warming strategies