Moorcheh Edge on Arduino UNO Q vs Ventuno Q: 1536-D Vector Benchmark

We compared two ARM64 edge boards running the same Moorcheh Edge workload: Arduino UNO Q (about 3.6 GB RAM) and Ventuno Q (about 15 GB RAM). Each board ingested and searched 1536-dimensional vectors in vector mode only — no text pipeline, no embedding model, no LLM. Queries were raw float vectors sent to POST /search.

For this benchmark we raised the per-store item limit to 1,000,000 so we could stress-test ingest and search at scale. Typical Moorcheh Edge deployments use a smaller cap suited to kiosk-sized catalogs. Even with Moorcheh's compact storage, 1M vectors is an extreme case; it shows how the two boards behave when the catalog grows.

For the earlier UNO Q RAG pipeline breakdown (embed + LLM vs retrieval), see Edge RAG on 4 GB Hardware.

Headline results: At 10k vectors, median search latency is a tie (about 25 ms on both). At 1M, Ventuno Q is about 3× faster on search (269 ms vs 833 ms median) and about 4× faster on full ingest (8 hours vs 32 hours wall clock).

Detailed tables (upload progress, 50 search samples per run, RAM during ingest, and the 50-query search + RAM study at 1M) are in the Google Sheets linked under Full results.

Why Moorcheh Edge makes this benchmark possible

A conventional 1M × 1536 float32 vector store is roughly 6 GB of embedding data alone (1,000,000 × 1536 × 4 bytes), before index structures and runtime overhead. That does not fit the practical memory budget on Arduino UNO Q and is a poor use of Ventuno Q if the goal is edge deployment rather than raw storage.

Moorcheh Edge binarizes vectors at ingest with MIB (Moorcheh Information Binarization) and retrieves with EDM (Enhanced Distance Metric) over those compact forms. In our runs:

• On disk: about 3.2 MiB (10k), about 32 MiB (100k), about 319 MiB (1M)
• In Docker at 1M: about 1.2–1.5 GiB while serving search

The same item counts on both boards confirm that store size is driven by Moorcheh's encoding, not by which CPU runs the server. That small footprint is why we could run a 1M × 1536 stress test on real edge hardware instead of only on a cloud instance.

How we ran the benchmark

We used one Moorcheh Edge server deployment on each board (ARM64, vector-only stack). The client ran on the board against localhost, so timings include HTTP JSON plus server work.

Procedure for each catalog size (10k, 100k, 1M):

1. Clear the store (fresh run at that scale).
2. Upload random unit vectors in batches until the target count is reached; record wall time and throughput.
3. Sample host and container memory during ingest.
4. Run 5 warmup searches, then 50 timed searches with top_k = 5, fixed seed = 42, and report min, median, mean, p95, and p99.

After the 1M run completed on each board, we ran a separate 50-query study on the loaded 1M catalog: before and after each search, record latency and RAM (host used memory and Docker stats for the Moorcheh container).

Both boards received the same software and the same test parameters; only hardware resources differ.

Full results

Every run is documented in two public Google Sheets — each contains the summary, per-query search latencies, upload progress, RAM samples during ingest, and the 50-query RAM worksheet:

• Ventuno Q — full benchmark workbook
• Arduino UNO Q — full benchmark workbook

Test configuration

Results: store size

On-disk store size was identical on both boards at every scale.

Moorcheh Edge loads the binarized catalog into memory for search; it does not keep full float32 matrices for every vector.

Results: upload (ingest)

At 10k, UNO Q ingest stays practical (about 1 minute). At 1M, ingest dominates wall clock: UNO Q needs on the order of 32 hours for a full load; Ventuno about 8 hours.

Peak host memory during ingest:

Both boards reach about 2.7 GB host use at 1M. UNO Q is near its ceiling; Ventuno still has room below its Docker limit.

Results: search latency (50 runs per scale)

Search cost grows with N. At kiosk scale (10k), both boards deliver about 25 ms median, which is suitable for interactive edge retrieval. At 1M, UNO Q is about 0.83 s per query vs Ventuno about 0.27 s. Latency scales roughly linearly with catalog size, consistent with scanning the full in-memory binarized index.

Results: 1M catalog, 50 queries with RAM per search

With 1M vectors already loaded, we measured each of 50 searches together with RAM immediately before and after the request. Typical host RAM stayed around 2.26 GB on UNO Q and 2.11 GB on Ventuno Q.

Per-query RAM barely changes during search because the catalog is already resident. The gap is CPU and system throughput, not index size.

Choosing a board

Arduino UNO Q fits Moorcheh Edge at 10k (and similar) catalog sizes: about 25 ms search, about 1 min ingest, about 3 MiB store. 100k is usable if about 100 ms retrieval is acceptable. 1M is viable as a stress experiment on this hardware but not as a default production target without long ingest times and about 800 ms-class search.

Ventuno Q runs the same Moorcheh Edge stack but is the better match for 100k–1M catalogs: lower search latency at scale and much shorter 1M ingest.

Methodology and limitations

1. Search timings include localhost HTTP JSON, not internal Rust-only timers.
2. Each run uses the same seed and query vector for repeatability, not a mix of query types.
3. We report vector ingest, search speed, and memory only (no text RAG quality or LLM tests).
4. Ventuno Q is our name for a higher-RAM ARM64 edge peer in this study.
5. Product store limits for typical edge use remain below the 1M cap used here; we raised the limit only to stress-test Moorcheh Edge at extreme scale.

Try Moorcheh Edge

pip install moorcheh-edge
moorcheh-edge up -y
moorcheh-edge status

• On-Edge introduction
• Edge product overview
• Research: From HNSW to Information-Theoretic Binarization

Benchmarks run 29 September – 1 October 2026.