ArcadeDB’s Python benchmark puts a price on using one engine for SQL, graphs and vectors
The unified engine matched Chroma’s vector recall and beat LadybugDB on transactional graph work, but specialist systems remained dramatically faster on analytics.
A newly posted benchmark of ArcadeDB’s embedded Python binding makes an unusually useful comparison: not whether one database can technically handle documents, graphs and vectors, but how much performance and memory a unified engine gives up to do all three. The paper, published in the SciPy 2026 proceedings and posted to arXiv on November 5, reports ArcadeDB 26.8.1 against SQLite 3.46.1, DuckDB 1.5.4, LadybugDB 0.18.1 and Chroma 1.5.9 on the Cross Validated Stack Exchange corpus.
One protocol, several very different workloads
Each backend ran alone in a Docker container pinned to eight CPU cores. The host used an Intel Core i9-12900HK and Samsung 980 PRO NVMe drive. Every main measurement was repeated five times in fresh containers; tables report the median and full range. The corpus contained about 426,000 posts, 346,000 users and 1.2 million 384-dimensional embeddings. Vector tests used 1,000 held-out queries and recall@10 against exact ground truth.
That rigor does not make every comparison perfectly symmetric. SQLite and ArcadeDB used relaxed durability for their headline transactional results, while DuckDB and LadybugDB synced every commit. The paper therefore also reports strict-sync checks for the affected comparisons.
Specialists still dominate analytics
On a five-query document-analytics suite, DuckDB finished in a median 9.3 milliseconds; ArcadeDB took 1,406.6 milliseconds—about 151 times longer. SQLite took 292.8 milliseconds. Ingest showed the same specialization penalty: ArcadeDB loaded the 426,000 posts in 17.52 seconds, versus 0.33 seconds for SQLite and 0.38 seconds for DuckDB.
Graph analytics were similarly lopsided. LadybugDB completed the four-query suite in 65.7 milliseconds, while ArcadeDB needed 839.6 milliseconds with its Graph Analytical View, about 12.8 times longer. ArcadeDB’s graph representation peaked at 11,037 MiB and occupied 1,840.8 MiB on disk, compared with 684 MiB and 41.4 MiB for LadybugDB.
Transactional graph work was the counterexample. At default durability settings, ArcadeDB delivered 3,212 operations per second against LadybugDB’s 525. With both forced to sync each commit, the gap narrowed to 595 versus 525 operations per second.
Vector search is the closest contest
At matched graph degree and ef_construction=100 / ef_search=100, ArcadeDB reached 0.980 recall@10, slightly above Chroma’s 0.972. ArcadeDB also used less peak memory: 21,650 MiB versus 25,212 MiB. Chroma still built faster—319.1 versus 546.1 seconds—and answered a query in 1.17 milliseconds versus ArcadeDB’s 4.15 milliseconds.
The tail deserves attention. ArcadeDB’s median vector-query latency was 3.86 milliseconds and its p99 was 7.11 milliseconds, but its worst observed query reached 145.9 milliseconds. Chroma’s corresponding maximum was 1.4 milliseconds.
The result is not a universal leaderboard. It is a workload decision. ArcadeDB’s demonstrated hybrid pipeline—vector search, SQL filtering and graph traversal over one store—finished in a 12.9-millisecond median across 20 warm repetitions. Teams that genuinely need that composition may accept the specialist gap to avoid duplicated data and cross-system consistency code. Workloads living mostly in one model still have a much simpler answer: use the specialist.
sources
comments · 0