Cross-Engine Benchmarks

Measured against Neo4j 5, Memgraph and FalkorDB. Every figure here is first-party — Samyama and the competitor measured through the same harness and, for LDBC, on the same host. That distinction is the point of the page, because the comparison numbers quoted in the FAQ are taken from competitors’ own published benchmarks, run on their hardware and their configuration.

Where these live, and why not in the open repo. Cross-engine runs depend on competitor configurations and the licence terms those runs are performed under, so they are maintained in the private samyama-graph-competitor-benchmarks repo and published selectively rather than continuously. The rule the engine applies: a number a reader can reproduce belongs next to the code that produces it; a number that required another vendor’s licensed software to obtain does not. A consequence worth stating: you cannot open the artifacts behind this page. Each figure below names the run it came from so it can at least be asked for by name.

LDBC SNB Interactive at SF10 — three engines, one host

Samyama, Neo4j 5 and FalkorDB on a single AWS r6a.8xlarge (2026-08-29):

The short reads are not clean, and that is the honest half of this section. They are the bar for the PERF-04 requirement and they fail it: IS3 at 7.41× and IS1 at 2.78×. That is a measured failure rather than an unmeasured one, which is the only thing to be said in its favour.

Two earlier runs of this benchmark are superseded and should not be requoted: 2026-08-19 (12 of 14 within 5×, IC6 timing out, IC11 at 11.5×, against Neo4j alone) and 2026-08-23 (13 of 14, IC11 at 9.4×). The progression is real, but quoting the old IC11 figure understates the engine by 4×, and quoting the old “85–170× slower on complex reads” figure is worse still — that one came from a run whose Samyama and competitor columns were measured on different machines.

Cypher conformance — openCypher TCK

One scenario list, one comparator, a per-engine driver that only executes and renders. The two columns are different runs on different corpora, so each carries its own provenance rather than implying a single measurement:

Read both columns. On the narrower set Samyama trails Neo4j by 13.9 points; on the wider one it leads by 17.6. The project’s own rule about the first column is blunt: 85% must never be quoted alone, because the gate it satisfies has two halves and only one is met — the absolute ≥85% bar passes with three scenarios of margin, while “within 5 points of the best competitor” needs 93.9%.

Every engine falls on the wider corpus, and Neo4j falls nearly twenty points. That is itself the evidence the expansion is sound rather than malformed: a corrupted corpus would have collapsed a mature engine to something implausible, not to 79.4%.

The Samyama figure on the wider set reads 97.0% here and 97.3% in the engine’s own-engine record. Both are right: the cross-engine comparison scores 3,766 scenarios through the judge path, the direct run evaluates 3,762. The judge figure is the one to compare against a competitor, because that is how the competitors were scored.

Scope, because this number is easy to over-quote. This is conformance, not performance and not scale. The competitor figures are one run of one container image each from 2026-08-24 — a fixed baseline, not a live measurement. Kuzu is absent: it is schema-first, so the TCK’s schema-free fixtures do not load. Four engines are not the field.

Hierarchy queries — and what the comparison leaves out

Against Neo4j on an identical graph, 94× across the 58 queries expressible on both engines.

That number is true and it is also a selection effect, which the earlier version of this chapter did not say. The 58 queries expressible on both engines are exactly the classes the index wins — H1, H2, H3, H5, H10. H4, H6 and H7 cannot be written in Neo4j at all, so the three classes where the index loses are absent from the 94× comparison by construction. That is what “expressible on both” means; it is not a rigged selection, but leaving it unsaid turns a scoped result into a general claim.

What the full corpus says, over the same 108 queries:

All three are true, and for a long time only the first was published. 34 of 108 queries are slower with the index, three classes by close to an order of magnitude: H7 lowest-common-ancestor 0.09×, H4 cross-hierarchy conjunction 0.21×, H6 anti-subsumption 0.49×. So the index does not pay for itself across its own corpus; it pays enormously on the shapes it was built for.

Two further caveats on the cross-engine figure itself: without the hierarchy index, Samyama is 1.6× slower than Neo4j on the same set, so the index is the differentiator rather than the engine. And H9’s apparent speedup is withdrawn — it has no independent baseline, because the baseline arm removes the very index its query requires.

What makes H2 and H10 win by orders of magnitude is that roll-up latency is flat in subtree size: 16.0 ns at one node, 16.6 ns at 137,257.

What this page is not

Each section is one suite’s result. Where the product stands across the whole requirement set — met, blocked, unmeasured, or measured only by proxy — is recorded in SCORECARD.json, assembled by the conformance harness from run envelopes. The count and the breakdown move with every run, so they are deliberately not transcribed here; the file is the source of truth. It lives with the cross-engine results, in the private repo, for the same reason they do.