Lifecycle

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.

These are the costs that nobody benchmarks and everybody pays. A session table opens a database, does one thing and closes it, for each kind of data the engine can hold, embedded and served. It is the cold measurement in its purest form.

A second table separates the two costs of running a database in another process: turning the answer into a wire format, and crossing a process boundary. A third deployment in between, a server inside the same process, tells them apart.

The durability table runs every timed write twice, once with the commit returning without waiting for the disk and once with the commit waiting for the log to be flushed and synced. It prints both with the ratio. Some engines have no such setting, and the table names them instead of comparing them against a setting they do not have.

The lane will carry these tables:

• A session for each kind of data, embedded and served. The embedded rows also carry what starting the process costs before the first database call, because an open measured inside an already-running process is not what someone launching a script pays.
• One projection answered at a range of result sizes by three deployments: in process, an HTTP server inside the same process, and a separate container. Read a row across to see which of the two costs grows with the answer.
• Every timed write at both durability settings, with the ratio, and the single-record read beneath the document writes as a control. The Size column names the operation rather than a corpus size, because the lanes that time a write do not write the same thing.

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.
• Cross-model: One operation across a vector, a graph edge, and a document.