Dauerhaftigkeit der gemessenen Datenbanken
Für diese Werte zur Leistung werden alle Datenbanken im persistenten Modus gemessen (Daten auf die Platte geschrieben, beim Neustart wieder eingespielt).
Gemessene Datenbanken
| Datenbank | Gemessene Version | Edition oder Lizenz | Protokoll | Messungen |
|---|---|---|---|---|
| gDown | main @ 087a1a5, 2026-10-16 | JVM build, benchmark settings | Bolt | Lasten |
| Neo4j | 5.26.31 community | Community (GPLv3) | Bolt | Lasten |
| Memgraph | 3.13.1 | Community (BSL 1.1) | Bolt | Lasten |
| FalkorDB | 0.0.1 on Redis 8.10.2 | SSPL 1.0 | RESP | Lasten |
| ArcadeDB | 26.10.1 | Apache 2.0 | Bolt | Lasten |
| TuGraph | 4.5.1 | Community (Apache 2.0) | Bolt | Lasten |
| Apache AGE | 1.8.0 on PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2) | Apache 2.0 (PostgreSQL extension) | JDBC | Lasten |
So läuft der Benchmark
| Eigenschaft | Wert |
|---|---|
| Architektur | arm64 |
| Maschine | Apple M4 Max, 16 logical CPUs, 64 GB RAM; Docker 29.8.2 |
| Grenzen der Container | 4 CPUs, 8 GB Speicher je Container |
| Graph der Lasten | 100,000 Knoten, 1,000,000 Beziehungen, mit festem Seed erzeugt |
| Läufe | 3 vollständige Läufe; jede Zahl ist der Median der Läufe |
| Clients | Ein Java-Client auf dem Host; je nach Last 1, 4, 8 gleichzeitige Clients |
| Protokoll | Der Transport jeder Datenbank (Tabelle oben): Bolt auf beiden Seiten für gDown und Neo4j; vor jeder Last eine Aufwärmrunde, nicht gezählt |
| Daten | 2026-10-07 – 2026-10-15 |
Start, Speicher, CPU und Größe
Ohne Index
| Last | gDown | Neo4j | Memgraph | FalkorDB | ArcadeDB | TuGraph | Apache AGE |
|---|---|---|---|---|---|---|---|
| Start bis zur ersten Antwort | 0.6 | 4.2 | 1.4 | 0.8 | 2.5 | 1.5 | 1.9 |
| CPU im Mittel (100 % = ein Kern) | 166 | 179 | 199 | 97 | 94 | 101 | 109 |
| CPU-Spitze | 401 | 384 | 408 | 155 | 212 | 408 | 244 |
| Speicherspitze | 519 | 4,814 | 538 | 436 | 6,425 | 374 | 477 |
| Daten auf der Platte | 176 | 836 | 389 | 39 | 83 | 165 | 529 |
Mit Indizes auf den Kennungen
| Last | gDown | Neo4j | Memgraph | FalkorDB | ArcadeDB | TuGraph | Apache AGE |
|---|---|---|---|---|---|---|---|
| Start bis zur ersten Antwort | 0.6 | 4.2 | 1.4 | 0.8 | 2.5 | 1.5 | 1.9 |
| CPU im Mittel (100 % = ein Kern) | 141 | 180 | 193 | 97 | 94 | 101 | 109 |
| CPU-Spitze | 397 | 380 | 412 | 154 | 212 | 408 | 244 |
| Speicherspitze | 978 | 4,813 | 505 | 429 | 6,425 | 374 | 477 |
| Daten auf der Platte | 182 | 837 | 389 | 39 | 83 | 165 | 529 |
Start: von docker run bis zur ersten Antwort auf RETURN 1, Median mehrerer Versuche, einmal gemessen und in beiden Konfigurationen gezeigt; die anderen Zeilen decken den ganzen Lauf der Lasten ab. CPU und Platte werden nicht gereiht: Eine Datenbank, die nichts Dauerhaftes schreibt, hat 0 MB auf der Platte.
Komplexe Lesezugriffe: mediane Latenz — LDBC SNB Interactive
Die 29 Abfragen der Interactive-Last des LDBC Social Network Benchmark (14 komplexe Lesezugriffe, 7 kurze, 8 Aktualisierungen; Apache 2.0, unverändert) laufen alle auf einem erzeugten Graphen mit dem SNB-Schema.
- 29 / 29 Abfragen ausgeführt: 14 komplexe Lesezugriffe, 7 kurze, 8 Aktualisierungen
- 3 / 3 Mitglieder eines 3-Knoten-Clusters liefern bei den 21 Lesezugriffen dieselbe Zeilenzahl
- 18 ms Median eines Schreibzugriffs, während der Leader 1.365 bestätigt (3.000 Personen)
- 0 ms Median eines Lesezugriffs auf einem Follower während dieser Schreibzugriffe (95. Perzentil: 30 ms)
Alle Datenbanken, 3,000 Personen
| Last | gDown | Neo4j | Memgraph | FalkorDB | ArcadeDB | TuGraph | Apache AGE |
|---|---|---|---|---|---|---|---|
| complex-1 | 2.3 | 7.5 | – | – | 12.3 | – | – |
| complex-2 | 1.2 | 2.4 | 3.8 | 209.0 | 3.3 | – | – |
| complex-3 | 9.0 | 10.3 | 8.9 | – | 19.5 | – | – |
| complex-4 | 0.9 | 2.2 | 1.1 | 0.6 | 2.5 | – | 126.1 |
| complex-5 | 4.7 | 10.1 | 4.9 | 2.5 | 16169.2 | – | – |
| complex-6 | 4.1 | 5.3 | 2.6 | – | 10.4 | – | – |
| complex-7 | 0.8 | 2.1 | 1.4 | – | – | – | – |
| complex-8 | 0.6 | 1.5 | 1.6 | 0.6 | 1.7 | – | – |
| complex-9 | 6.0 | 5.8 | 16.9 | – | 16.6 | – | – |
| complex-10 | 1.1 | 4.8 | – | – | – | – | – |
| complex-11 | 0.9 | 2.4 | 1.4 | 0.6 | 2.5 | – | – |
| complex-12 | 1.7 | 2.6 | 4.4 | – | 3.1 | – | – |
| complex-13 | 0.9 | 1.6 | – | – | 1.2 | – | – |
| complex-14 | 0.8 | 2.2 | – | – | 1861.0 | – | – |
Ein Strich: Die Datenbank lehnt die Abfrage ab, überschreitet ihr Zeitlimit oder liefert eine andere Zeilenzahl als Neo4j (ihre Zeit sagte dann nichts aus). Fall für Fall:
Alle Datenbanken, 30,000 Personen
- complex-1 : gDown 12.9 ms, Neo4j 51.5 ms
- complex-2 : gDown 2.8 ms, Neo4j 2 ms
- complex-3 : gDown 15.1 ms, Neo4j 13.3 ms
- complex-4 : gDown 1.6 ms, Neo4j 1.7 ms
- complex-5 : gDown 19.5 ms, Neo4j 16.9 ms
- complex-6 : gDown 6.7 ms, Neo4j 7 ms
- complex-7 : gDown 1.4 ms, Neo4j 1.4 ms
- complex-8 : gDown 0.8 ms, Neo4j 1 ms
- complex-9 : gDown 15.1 ms, Neo4j 8.5 ms
- complex-10 : gDown 4.4 ms, Neo4j 4.2 ms
- complex-11 : gDown 1.9 ms, Neo4j 1.8 ms
- complex-12 : gDown 2 ms, Neo4j 2.4 ms
- complex-13 : gDown 0.9 ms, Neo4j 1 ms
- complex-14 : gDown 4 ms, Neo4j 3.3 ms
Median über 5 Personen nach einer Aufwärmrunde, ein Durchlauf je Datenbank, in Containern mit den Grenzen der Tabelle zum Aufbau; jede Datenbank wird über ihren eigenen Transport angesprochen (Bolt auf beiden Seiten für gDown und Neo4j: der Round-Trip zählt auf beiden Seiten). „< 1 ms“: der Median rundet auf null Millisekunden. Kurze Lesevorgänge: Median unter einer Millisekunde für gDown (0,5 bis 0,7 ms) gegenüber 0,7 bis 1 ms für Neo4j, gleiches Protokoll auf beiden Seiten.
Bei 3.000 Personen (90.000 Knoten und 470.000 Beziehungen, per Raft in 16 s geladen) bleiben die Mediane unter 60 ms. Zwei Optimierungen, die dieser Test gefunden hat: complex-1 sank von 0,6 s auf 34 ms, complex-14 von 2 s auf 8 ms.
Keine offiziellen LDBC-Ergebnisse: Diese Zahlen sind von der Last LDBC SNB Interactive abgeleitet und wurden nicht vom LDBC (Linked Data Benchmark Council) auditiert. Die Daten erzeugt der Test, nicht der LDBC-Datagen: Die Zeiten sind mit veröffentlichten LDBC-Ergebnissen nicht vergleichbar. Ein Lauf pro Konfiguration. Der Test fand außerdem zwei Fehler, die behoben sind.
Quelle: gluonify-gdown, README und Berichte von LdbcSnbTest und LdbcClusterTest.
Die Cypher-Abdeckung (das openCypher-TCK auf jeder Datenbank) steht auf der Vergleichsseite.
Latenz und Durchsatz, Last für Last
Gleicher Graph, gleiche Abfragen und gleiche Maschine für jede Datenbank der Tabelle oben: Die Zahlen unten sind der Median über die Läufe der Tabelle zum Aufbau, gemessen auf arm64.
Die Latenz ist der Median (p50) in Millisekunden, kleiner ist besser; die Lasten mit mehreren Clients sind in Anfragen pro Sekunde, größer ist besser. Der beste Wert jeder Zeile steht fett. Über die Standardwerte jedes Images hinaus ist nichts abgestimmt; gDown läuft auf der JVM mit 6 GB Heap und 2 GB Seitencache, Neo4j mit 4 GB Heap und 2 GB Seitencache. Jeder Lauf startet in einem frischen Container, lädt den Graphen in UNWIND-Stapeln, prüft, dass die Datenbanken bei den Ergebnissen übereinstimmen, und misst dann.
Ohne Index
| Last | gDown | Neo4j | Memgraph | FalkorDB | ArcadeDB | TuGraph | Apache AGE |
|---|---|---|---|---|---|---|---|
| Lesen nach Kennung | 0.29 | 0.74 | 0.56 | 0.18 | 0.86 | 0.49 | 0.24 |
| Lesen nach Eigenschaft | 11.7 | 7.93 | 7.05 | 2.39 | 0.42 | 0.47 | 0.25 |
| Bereich über eine Eigenschaft (100 Werte) | 17.4 | 10.8 | 11.6 | 3.11 | 23.7 | 76.7 | 0.26 |
| Zählen eines Labels | 0.38 | 0.74 | 4.03 | 0.19 | 0.46 | 97.9 | 9.37 |
| 1 Sprung | 0.28 | 0.52 | 0.40 | 0.19 | 0.40 | 0.51 | 0.27 |
| 2 verschiedene Sprünge | 0.35 | 0.56 | 0.41 | 0.21 | 0.45 | 0.61 | 0.73 |
| 3 verschiedene Sprünge | 0.88 | 1.17 | 0.71 | 0.34 | 1.07 | 1.37 | 5.61 |
| Gruppieren + Top 10 | 3.94 | 10.9 | 32.6 | 14.9 | 8.74 | 145 | 62.5 |
| Filter + Aggregat | 24.4 | 11.7 | 9.94 | 3.47 | 5.51 | 78.3 | 24.0 |
| Zählen eines Musters (alle KNOWS zwischen Personen) | 21.4 | 219 | 59.9 | 31.4 | 101 | 827 | 45.9 |
| Heiße Lesevorgänge + eine vollständige Traversierung pro 100 | 0.32 | 0.57 | 0.41 | 0.19 | 0.41 | 0.53 | 0.31 |
| Erste 10 Zeilen eines großen Ergebnisses | 0.33 | 0.59 | 0.46 | 0.20 | 0.60 | 0.56 | 0.21 |
| Schreiben: 1 Knoten pro Anfrage | 0.47 | 0.57 | 0.57 | 0.35 | 0.56 | 0.49 | 0.26 |
| Schreiben während einer langen Traversierung | 0.66 | 0.54 | 0.71 | 35.0 | 0.80 | 0.60 | 0.28 |
| 8 Clients: 1 Sprung | 16,239 | 8,437 | 9,811 | 28,458 | 10,525 | 4,249 | 16,372 |
| 4 Clients: Schreiben | 6,801 | 5,223 | 3,260 | 4,652 | 3,364 | 3,675 | 9,280 |
ArcadeDB (indiziert) wird immer mit Index gemessen: Seine internen Kennungen schließen die Suche über id() der anderen Spalten aus. Seine Spalte steht hier, damit nichts fehlt, aber seine Verhältnisse ohne Index vergleichen einen Index mit einem Scan: Für den fairen Vergleich siehe die Tabelle mit Indizes.
Mit Indizes auf den Kennungen
| Last | gDown | Neo4j | Memgraph | FalkorDB | ArcadeDB | TuGraph | Apache AGE |
|---|---|---|---|---|---|---|---|
| Lesen nach Kennung | 0.30 | 0.73 | 0.50 | 0.18 | 0.86 | 0.49 | 0.24 |
| Lesen nach Eigenschaft | 0.27 | 0.52 | 0.38 | 0.20 | 0.42 | 0.47 | 0.25 |
| Bereich über eine Eigenschaft (100 Werte) | 0.32 | 0.48 | 0.37 | 0.21 | 23.7 | 76.7 | 0.26 |
| Zählen eines Labels | 0.26 | 0.46 | 3.77 | 0.17 | 0.46 | 97.9 | 9.37 |
| 1 Sprung | 0.26 | 0.46 | 0.34 | 0.19 | 0.40 | 0.51 | 0.27 |
| 2 verschiedene Sprünge | 0.32 | 0.51 | 0.36 | 0.21 | 0.45 | 0.61 | 0.73 |
| 3 verschiedene Sprünge | 0.82 | 1.00 | 0.51 | 0.33 | 1.07 | 1.37 | 5.61 |
| Gruppieren + Top 10 | 4.75 | 9.63 | 32.3 | 14.9 | 8.74 | 145 | 62.5 |
| Filter + Aggregat | 21.2 | 16.5 | 9.82 | 3.41 | 5.51 | 78.3 | 24.0 |
| Zählen eines Musters (alle KNOWS zwischen Personen) | 20.9 | 225 | 62.4 | 31.3 | 101 | 827 | 45.9 |
| Heiße Lesevorgänge + eine vollständige Traversierung pro 100 | 0.32 | 0.54 | 0.40 | 0.19 | 0.41 | 0.53 | 0.31 |
| Erste 10 Zeilen eines großen Ergebnisses | 0.34 | 0.55 | 0.46 | 0.21 | 0.60 | 0.56 | 0.21 |
| Schreiben: 1 Knoten pro Anfrage | 0.42 | 0.55 | 0.59 | 0.36 | 0.56 | 0.49 | 0.26 |
| Schreiben während einer langen Traversierung | 0.66 | 0.56 | 0.60 | 35.0 | 0.80 | 0.60 | 0.28 |
| 8 Clients: 1 Sprung | 16,135 | 8,609 | 9,882 | 28,302 | 10,525 | 4,249 | 16,372 |
| 4 Clients: Schreiben | 6,842 | 5,192 | 3,314 | 4,423 | 3,364 | 3,675 | 9,280 |
Laden des Graphen
Ohne Index
| Last | gDown | Neo4j | Memgraph | FalkorDB | ArcadeDB | TuGraph | Apache AGE |
|---|---|---|---|---|---|---|---|
| Ladezeit | 6.4 | 8.8 | 4.9 | 5.8 | 15.2 | 110.5 | 99.0 |
| Laderate | 172,107 | 125,063 | 224,642 | 188,301 | 72,488 | 9,954 | 11,115 |
Mit Indizes auf den Kennungen
| Last | gDown | Neo4j | Memgraph | FalkorDB | ArcadeDB | TuGraph | Apache AGE |
|---|---|---|---|---|---|---|---|
| Ladezeit | 10.9 | 11.0 | 6.0 | 40.8 | 15.2 | 110.5 | 99.0 |
| Laderate | 101,280 | 99,864 | 183,114 | 26,988 | 72,488 | 9,954 | 11,115 |
Was man daraus mitnimmt
- FalkorDB ist bei kurzen Operationen (Lesen nach Kennung, Sprünge, Schreiben eines Knotens) und beim Durchsatz mit mehreren Clients am schnellsten, mit dem kürzesten Client-Weg (RESP). Sehen Sie sich „Schreiben während einer langen Traversierung“ an: Seine Schreibvorgänge warten hinter einem langen Lesen; es schreibt standardmäßig nichts Dauerhaftes, und sein Laden mit Indizes ist das langsamste.
- gDown ist bei den meisten Lasten schneller als Neo4j (geometrisches Mittel unter 1 in beiden Konfigurationen), lädt schneller und hält seine Daten auf weit weniger Plattenplatz. Gleichauf oder langsamer ist es bei den ersten Zeilen eines großen Ergebnisses und beim Schreiben eines Knotens: siehe diese Zeilen.
- Gegenüber Memgraph gewinnt gDown beim Gruppieren, bei Label-Zählungen und beim Durchsatz mit 8 Clients und verliert bei kurzen Lesevorgängen, Sprüngen und Schreibvorgängen. Memgraph erzwingt seine Commits nicht jedes Mal auf der Platte, anders als gDown und Neo4j.
- ArcadeDB, immer mit Index gemessen, ist beim Lesen konkurrenzfähig, aber langsam bei Bereichen und bei Schreibvorgängen mit mehreren Clients.
- Speicher: Die Datenbanken, die alles im RAM halten (Memgraph, FalkorDB), brauchen am wenigsten. gDown und Neo4j laufen hier mit großzügigen Heaps, und gDown kommt mit einem kleineren Heap bei gleichen Latenzen mit weit weniger aus (siehe die native Messung oben).
Was dieser Vergleich nicht sagt
- Die Dauerhaftigkeit unterscheidet sich: gDown und Neo4j synchronisieren bei jedem Commit auf die Platte; Memgraph nur alle 100 000 Transaktionen; FalkorDB schreibt standardmäßig nichts Dauerhaftes; die Einstellungen der anderen Datenbanken wurden nicht geprüft. Die Schreibzeilen vergleichen daher nicht dieselbe Garantie.
- Die Datenbanken, die Bolt sprechen, teilen sich denselben Java-Treiber; FalkorDB wird mit einem für den Benchmark geschriebenen minimalen RESP-Client gemessen, der seinen Weg beim Lesen verkürzt (siehe die Spalte Transport).
- ArcadeDB wird in beiden Tabellen immer mit Index gemessen (seine internen Kennungen schließen die Suche über id() aus); eine Datenbank ohne Wert in einer Konfiguration wurde dort nicht gemessen.
- Der Graph passt bei allen in den Speicher. Ein Graph größer als der RAM, Replikation, Ausfallübernahme, Vektorsuche, Graphalgorithmen und Lesen während gleichzeitiger Schreibvorgänge sind nicht gemessen. Je Datenbank ein Knoten.
- ArcadeDB läuft mit unbegrenztem Heap: Seine Speicherzahl ist nicht vergleichbar. Sein Image ist ein Entwicklungsstand.
- Eine Maschine, die nicht im Leerlauf war, wenige Läufe: Rechnen Sie mit ±10 % pro Zelle.
Quelle: gluonify-gdown, die Rohergebnisse jedes Laufs (docs/bench) und scripts/bench-compare.py, von einem Skript dieser Website zusammengesetzt; das Benchmark-Skript liegt im selben Repository.