Cross-model

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.

Most lanes compare engines that do one thing. This lane asks what a single engine buys when one operation touches more than one data model. The comparators are other engines that hold several models and, beside them, a composed stack: separate stores with application code between them.

The retrieval path is a vector search, a one-hop expansion from what it found, and a projection of the documents behind those. A second path restricts the vector search to the neighbourhood of a starting node. Both report recall against a brute-force answer over the same candidate set.

The crash table is a correctness result, not a speed one. The same operation is interrupted part-way through, many times, and afterwards the store is asked what it holds. It has no latency column on purpose.

The lane will carry these tables:

• The composed write, the retrieval path, and the graph-filtered vector search, with recall for the two read paths. The write is a transaction on the engines that have one and a sequence of calls on the stack that does not.
• Interrupted composed operations, and how many of them left the store holding half of one. This table has no latency column on purpose: it is a correctness result, not a speed one.
• Which multi-model engines have rows on which table, read from the published tables. Each cell says whether the engine was measured there, was left off with a reason the table itself prints, or was not run on that workload at all.

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.
• Vectors: Dense and sparse vector search, with recall beside every latency.
• Time series: Monitoring-style queries over timestamped readings.
• Lifecycle: Opening, closing, deployment boundaries, and what waiting for the disk costs.