Vectors

The first results are published in November 2026: ArcadeDB 26.11.1 against a multi-model subset of engines, measured on the November instrument. Until then MMDBBench shows its method and its lanes, and no numbers.

Dense and sparse vectors are different problems with different engines behind them, so they get separate tables. Both report recall beside every latency. An approximate index can be made fast by returning worse answers, so a latency without the share of true neighbours it found is not a comparable number.

Recall is measured against an exact brute-force answer over the same corpus. For an approximate index, agreeing with the exact answer is a stronger check than agreeing with another engine.

Where an engine has the boundary, loading the data and building the index are timed separately. A search after inserting into a built index, and a search after deleting from one, are timed as well.

The lane will carry these tables:

• Dense search, and search after an insert and after a delete into the same built index, with recall beside each. Every row states what it stores, full precision or quantized, because a quantized index and a full-precision one are not the same measurement.
• Sparse search on real learned sparse vectors, with recall beside every latency. Loading and indexing are one timer on this table: the engines here build the index while ingesting, so the boundary the dense table splits does not exist.

The rules every result follows are in the methodology. The settings for each engine are on the engines page. If one is wrong, tell us.

• Tables: Documents and structured query language (SQL) analytics.
• Graphs: Interactive and analytical queries on a social network graph.
• Time series: Monitoring-style queries over timestamped readings.
• Cross-model: One operation across a vector, a graph edge, and a document.
• Lifecycle: Opening, closing, deployment boundaries, and what waiting for the disk costs.