Memory & disk footprint (preliminary)

How much machine does Aito need? On a 10M-row linked-invoice database, the v2 engine stores the same state in 3,258 MB on disk — 2.3× less than the v1 engine — and holds its working set in 597 MB of JVM heap, 3.8× less than v1 in the configuration measured below.

Read the disk figure as the durable one. It is a property of the on-disk format: the priors A/B measured it as bit-identical with the link-target priors on and off, because those caches are never persisted. The heap figure is the one that decides how many tenants fit on a box, but it moves with configuration, so it is stated here with that configuration attached rather than as a headline ratio. The configuration, and what the served default costs, are in the provenance note under the table.

The measurement

Both engines were pointed at the same optimized 10M-row state, same corpus, same build, each given a 4 GB heap:

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 gap in the table 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.

The v2 column has one production default switched off, and the cost of that is now measured. Linked-table priors are enabled by default in a served database and disabled in the benchmark arm that produced this column. They are caches that live as long as the database object, so they can only add heap — and re-running the same case with them enabled, at the same pinned -Xmx, adds a little over two per cent. The engine ratio therefore moves by a rounding step rather than collapsing, and the on-disk and memory-mapped columns are unaffected because priors are never persisted. What this column still is not: a ladder (see above), or a measurement under write load.

Hardware is unspecified. Single dev machine. The ratio between the two columns is the durable signal; the absolute megabytes depend on the box.

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
• Clustering (preview) · Warming strategies