ArcadeDB

Most databases that call themselves multi-model are several engines behind one API. ArcadeDB is not. Everything it stores sits on the same pages, goes through the same write-ahead log, and commits in the same transaction, so a write that touches a document, an edge and a vector index is one ACID transaction, atomic and durable as a unit, instead of three that have to be coordinated.

The indexes work the same way. LSM trees, full-text, geo, hash, and both dense and sparse vector indexes are all commit in the same transaction as the records they index. Replication comes along for the ride: Raft ships page changes from that shared log, so every model replicates correctly without anyone writing replication code per model.

Vectors are the exception worth naming. The vector records are transactional, logged and replicated like everything else, but the nearest-neighbour graph used to search them is not: it is built in the background and can be rebuilt. The data is the source of truth and the search structure catches up to it. A transactional record with an eventually consistent index over it is more than a standalone vector store offers, and less than a fully transactional index would be.

ArcadeDB is a Java engine, and that is friction for Python work: a separate runtime to install, a service to start, and a network hop between your code and your data. The embedded distribution removes all three. It ships the upstream engine unmodified, with a bundled runtime and platform wheels, so uv add arcadedb-embedded or pip install arcadedb-embedded is the entire setup and the database runs in your process.

This is a real package surface rather than a launcher. Transactions and lifecycle, schema and graph helpers, bulk ingest, import and export paths, and the vector features are all exposed and tested, with the example suite run in CI on every change.

Both halves of this work are maintained here. Fixes and features found through the benchmarking below are filed and, where possible, contributed upstream, so the engine and the Python distribution improve together rather than diverging.

The obvious question is what the Python boundary costs. The engine runs at the same speed either way; what gets charged for is handing results back. Against an in-process Java baseline doing the same work, a vector search costs 1.28x and a 100k-row scan 1.63x.

The more useful number is the one inside Python. Asking for row objects is 13.8x slower than asking for columns over the identical query, so which call you reach for matters far more than the language boundary does. Which call you reach for is worth checking before blaming the engine for a slow loop.

Graph is what most people reach for ArcadeDB to do, so it goes first. The benchmark is LDBC-SNB, the Linked Data Benchmark Council's Social Network Benchmark, a standard synthetic social network, and the queries are Cypher, which is the language most graph work is written in. Neo4j is the engine anyone choosing a graph database weighs it against. LadybugDB is here because it is embedded and columnar, which makes it the closest comparison to running ArcadeDB inside your own process.

ArcadeDB embedded answers all four queries faster than Neo4j, at both sizes, by margins the table makes plain. That is the strongest head-to-head result on this page, and it is the one a graph user is looking for.

Analytical queries over the whole graph are a different job from those single traversals, and ArcadeDB has a separate mechanism for them. A Graph Analytical View is an in-core projection of the graph, built once, that the planner uses for queries touching most of the vertices instead of a handful. Because it is optional, it can be switched off, so the table below carries the same engine twice and the cost of the mechanism is visible rather than assumed.

Vector search is the newest of these models and the one with the most specialised competition, so it gets the most detailed treatment here: two corpora, two kinds of vector, and recall reported beside every latency. It is also the workload ArcadeDB does not win, which the tables show rather than bury. Every corpus below is real and published, never generated, which matters most for the sparse case.

A SPLADE (Sparse Lexical And Expansion model) vector stores one weight per word in the vocabulary, and nearly every weight is zero, so a search only has to look at the few words a query actually uses. Those words cost wildly different amounts. A common word has to be checked against a huge number of documents; a rare one against almost none.

Real writing has a few words that appear everywhere and a very long tail that appear almost nowhere, so some queries are far more expensive than others. Generated data spreads words out evenly, which quietly removes the expensive case and makes any approximate index look better than it is. Dense search uses published image descriptors for the same reason.

MS MARCO is a public search-relevance corpus, and the sparse vectors come from Big-ANN, a benchmark challenge for approximate nearest-neighbour search at scale. SIFT and DEEP are standard image-descriptor sets. Latencies below are p50, the median query.

Two of those sizes are ceilings rather than choices. 8.84 million is the entire Big-ANN sparse base set, so no larger sparse tier exists to run, and DEEP's 9.99 million is the ten-million slice that ships with exact ground truth. The dense corpora are also narrow beside a modern text embedding, which runs 768 to 3072 numbers wide against SIFT's 128 and DEEP's 96. That width is fixed by how the descriptors were produced, and these sets earn their place anyway by publishing exact nearest neighbours at ten-million scale, which is what makes recall comparable across engines at all. It does mean the dense rows describe index behaviour at 96 and 128 dimensions, and a 1536-dimension embedding is a different question.

The index settings are matched rather than left to each vendor's defaults. Dense search builds HNSW at ef_construction 100 and queries at ef_search 100 everywhere, with a graph degree of 16 neighbours per node. ArcadeDB spells that maxConnections 32, because its bound is per layer while hnswlib-style engines double theirs at the base layer, so matching the numeral instead of the degree would have handed ArcadeDB twice the graph. Sparse search has no equivalent knob, so every engine runs its own defaults there and each table states what precision the index stores. Every query asks for the top 10.

Recall is reported next to every latency. A vector benchmark without a quality number is not a comparison, since any engine can be made faster by searching less thoroughly, and the engines here sit at genuinely different points on that trade.

Every engine in every table below runs in the same container envelope, one at a time on one machine, and each cell is the median of five repetitions rather than a single sample. The exact build measured sits under each table.

A fair question about the table above: those are first-pass numbers, taken right after each index is built. Does the picture change once an engine has warmed up? For sparse search, barely.

The same harness runs tabular work in both OLTP and OLAP shapes, time series on TSBS, the Time Series Benchmark Suite, and a cross-model transaction that starts from a vector hit, traverses the graph, and updates a document. The tables below and the summary figure at the end all use compressed labels, which are worth having to hand:

The cross-model transaction is the argument for a unified engine stated as an experiment rather than a claim. Against a composed stack of a vector store plus a graph database, the interesting output is not the latency, it is what a failure part-way through leaves behind.

One operation writes both stores in turn: the graph database takes the update first, the vector store gets its copy second. We deliberately raise an error in the gap between the two, which is a gap that exists in any design where two systems acknowledge separately. The composed stack is left half-updated. The graph database has durably kept a write the vector store never received, the two disagree about the same records from then on, and neither one knows anything is wrong.

That damage stays. Nothing goes back to look for it, so the only records that ever recover are the ones some later write happens to touch again. The corruption is partial and silent rather than obvious, which is the awkward part: you cannot find it by spot-checking a few records. A single engine wrapping the same work in one transaction simply undoes all of it, leaving the counters exactly where the completed operations left them.

We interrupted 200 operations against each system. The composed stack was left half-updated in all 200. ArcadeDB and SurrealDB, each wrapping the work in one transaction, were left half-updated in none of them. The count is worth stating because a handful of trials would not settle it: with five attempts and no failures you cannot rule out a failure rate near one in two, where two hundred puts it under two in a hundred. Before each interruption the two stores are checked and found to agree exactly, which is what makes a disagreement afterwards mean something.

One thing this is not: a criticism of Qdrant or Neo4j. Both do exactly what they are asked, correctly, every time. The gap is between them, and it would appear just the same with any other pair. Nor does it mean a setup like this cannot be made to work. A team building on two stores would add machinery to repair the divergence afterwards, replaying the write that went missing until both sides agree, and with that in place the damage is eventually mended rather than permanent. What the experiment measures is what that machinery costs you, since it is the thing a single engine with one transaction does not need.

One figure for all of it. Every row above appears here as a ratio against the strongest comparator for that workload.

The tables above run the same engine version in both deployments, so the difference between them is deployment and not the engine. Running the database in a separate process costs something, and that cost is really two things added together: packing the answer into a format that can travel over a connection, and the connection itself. The table below separates them by measuring a third setup in between, an HTTP server running inside the same process. Embedded to that middle setup adds the packing without adding a second process. The middle setup to a separate container adds the second process without changing the packing.

The two are nowhere near equal, which is the useful part. Packing the answer costs something at every size and grows with the result. The process boundary is so small that at the smaller sizes it disappears into the noise and measures slightly negative. So the cost of running client and server as separate processes on one machine is essentially the serialization, not the separation, and the lever that would actually move it is a cheaper wire format rather than co-location.

Use the embedded distribution when the database serves one process: notebooks, tests, single-node services, agent tooling, and anything where a network hop per query is pure cost. It installs with pip, starts in milliseconds, and has no service to operate.

Use the server when more than one process or machine needs the same data, when you want the Postgres, Redis, Bolt or HTTP wire protocols, or when you need Raft replication and failover. The embedded package can also start a server in-process, so this is not a one-way door.

This is a deployment decision, not a performance one. The engine is the same in both, and the difference you will feel is the boundary you put around it.