Graphdatenbank-Benchmark: Neo4j vs FalkorDB vs Memgraph

Wir haben Neo4j, FalkorDB und Memgraph anhand eines synthetischen Graphen einem Benchmark unterzogen, der aus 120.000 Amazon-Produktbewertungen abgeleitet wurde (381K Knoten, 804K Kanten). Wir führten 12 Abfragevorlagen mit jeweils 1.000 Messungen aus, testeten die Datenaufnahme bei 6 Stapelgrößen, hielten eine gleichzeitige Last für 60 Sekunden bei bis zu 32 Threads aufrecht und maßen Speicher, Kaltstart, gemischte Arbeitslast und Indexauswirkungen.

FalkorDB lieferte bei 8 Threads einen höheren Durchsatz als Neo4j und Memgraph.

Ergebnisse des Graphdatenbank-Benchmarks

Gleichzeitiger Durchsatz

QPS (Abfragen pro Sekunde) misst, wie viele Leseabfragen die Datenbank pro Sekunde unter anhaltender Last mit mehreren Threads beantwortet. Jeder Lauf dauert 60 Sekunden. Höher ist besser.

Abfragelatenz (p50)

p50 ist die mittlere Latenz: Die Hälfte aller Abfragen wird schneller als dieser Wert abgeschlossen. Niedriger ist besser.

• Punktabfrage: Einen einzelnen Knoten anhand der ID abrufen. Die Redis-Hashtabellen von FalkorDB führen O(1)-In-Memory-Lookups durch, etwa 3x schneller.
• Traversierung: Von einem Knoten zu seinen Nachbarn (1-Hop) oder Nachbarn der Nachbarn (2-Hop) wandern. FalkorDB erledigt 2-Hop 2.9x schneller.
• Aggregation: Bewertungen pro Marke zählen, durchschnittliche Sternebewertungen berechnen.
• Filter + Scan: Bewertungen nach Sternebewertung im gesamten Dataset filtern.

Aufnahmedurchsatz

Der Aufnahmedurchsatz misst, wie viele Bewertungen pro Sekunde die Datenbank schreiben kann. Jeder Punkt im Diagramm entspricht einer anderen Stapelgröße: wie viele Bewertungen zu einer einzigen Abfrage gruppiert werden. Höher ist besser.

Bei Stapelgröße 1 liegt Memgraph vorn (1.427/s). Mit zunehmender Stapelgröße skaliert FalkorDB steil und überholt Memgraph bei Stapel 500. Neo4j erreicht unabhängig von der Stapelgröße ein Plateau bei ~10.600/s. Bei Stapel 5.000 erreicht FalkorDB 22.784/s, das 77x seiner Leistung bei Stapel 1.

Sie können mehr über unsere Graphdatenbank-Benchmark-Methodik erfahren.

Wichtigste Erkenntnisse

FalkorDB erreicht 6.693 QPS bei 8 Threads, 6.7x Neo4j

Die In-Memory-Datenstrukturen und die Ereignisschleife von Redis ermöglichen es, Abfragen mit geringer Latenz und hoher Parallelität zu kombinieren. Nach 8 Threads erreicht der Durchsatz ein Plateau, da der Single-Threaded-Kern von Redis die Obergrenze darstellt. Neo4j erreicht seinen Höchstwert bei 16 Threads (1.010 QPS) und fällt dann bei 32 (927 QPS) ab, was auf Thread-Konflikte hindeutet.

FalkorDB startet kalt in 1.1ms, 82x schneller als Neo4j

Neo4j benötigt nach einem Neustart 90ms, um seine erste Abfrage anzunehmen. Die erste Aufwärmabfrage läuft mit 274ms, danach benötigt es etwa 3 Abfragen, um sich auf 34ms einzupendeln. FalkorDB ist in 1.1ms bereit, die erste Abfrage in 0.4ms. In einem Microservice- oder Serverless-Setup, in dem Pods hoch- und herunterskaliert werden, ist dieser Unterschied von Bedeutung.

Indizes: 1.700x Unterschied bei Neo4j, ~1x bei FalkorDB

Ohne Indizes benötigte Neo4js Abfrage deep_feature_products 293ms. Mit Indizes 0.17ms. Das ist ein Unterschied von 1.712x. Memgraph zeigte eine ähnliche Empfindlichkeit (160-898x je nach Abfrage). FalkorDBs Ergebnisse blieben mit oder ohne Indizes ungefähr gleich, da Redis-Hashtabellen bereits als implizite Indizes fungieren.

Speicher: 415MB vs 2.668MB für denselben Graphen

• Memgraph: 415MB
• FalkorDB: 496MB
• Neo4j: 2.668MB (JMX-Heap verwendet)

Die JVM von Neo4j reserviert beim Start 4GB vorab, sodass der prozessbezogene Speicher (VmRSS) unabhängig von der tatsächlichen Datennutzung immer bei ~5.2GB liegt. Die JMX-Heap-Metrik ist die aussagekräftige. Der Spitzenwert von 2.7GB ist der Wert, der für die Kapazitätsplanung verwendet werden sollte.

Neo4j gewann die schwerste Aggregation

FalkorDB hatte die niedrigste Latenz bei 11 von 12 Abfragen. Die Ausnahme war agg_feature_sentiment (Gruppierung nach Stimmung mit Filterung), bei der Neo4js Abfrageoptimierer einen besseren Ausführungsplan erstellte: 131ms gegenüber FalkorDBs 152ms.

Gemischte Arbeitslast (80 % Lesen, 20 % Schreiben)

8 Threads, 60 Sekunden, null Fehler in allen drei Datenbanken:

• FalkorDB: 50.223 ops (837 QPS)
• Neo4j: 44.256 ops (738 QPS)
• Memgraph: 28.040 ops (467 QPS)

Schreiboperationen haben die Leseleistung bei keiner der Datenbanken merklich beeinträchtigt.

Architekturen in diesem Benchmark

Jede Datenbank wird mit einer eigenen Verwaltungsoberfläche ausgeliefert. Diese Screenshots zeigen dasselbe Dataset (16.127 Knoten, 24.318 Kanten), geladen in alle drei, wobei dieselbe COMPARED_WITH-Traversierungsabfrage ausgeführt wird.

FalkorDB

FalkorDB ist ein Graphmodul, das auf dem In-Memory-Key-Value-Speicher von Redis basiert. Abfragen sind openCypher, darunter liegen jedoch Redis-Hashtabellen. Deshalb liegen Punktabfragen bei 0.044-0.048ms.
Die beiden anderen Datenbanken in diesem Benchmark maßen bei denselben Abfragen 2-3x höhere Werte. Der Kompromiss besteht darin, dass der Single-Threaded-Kern von Redis bedeutet, dass der gleichzeitige Durchsatz ab 8 Threads nicht weiter skaliert.

Neo4j

Neo4j läuft auf der JVM. JIT-Kompilierung bedeutet, dass wiederholte Abfragen im Laufe der Zeit schneller werden (Aufwärmen: 274ms -> 34ms). GC-Pausen beeinflussen die Tail-Latenz, werden aber durch die IQR-Ausreißer-Entfernung abgefangen. Der Abfrageoptimierer bewältigt komplexe Aggregationspläne gut, und daraus resultiert der agg_feature_sentiment-Gewinn. Die Kosten sind 4GB Heap-Vorabzuweisung und GC-Overhead.

Memgraph

Memgraph ist in C++ geschrieben. Kein JVM-Overhead. 415MB für das gesamte Dataset, das niedrigste der drei. Am schnellsten bei einzelnen Einfügungen (1.427/s) dank minimalem Overhead pro Abfrage. Aber es fällt beim gleichzeitigen Durchsatz zurück (684 QPS Spitze). Bolt-kompatibel, daher funktioniert es mit dem Neo4j-Treiber.

Methodik des Graphdatenbank-Benchmarks

Umgebung

• RunPod 8 vCPU (AMD EPYC x86_64), 32GB RAM, Ubuntu 24.04 LTS
• Native Installation, kein Docker. Alle drei Datenbanken auf demselben Rechner, localhost-Verbindungen.
• Python 3.12.3. Persistente Sitzungen für Single-Threaded-Tests, Sitzungen pro Aufruf aus einem Verbindungspool für Multi-Threaded-Tests.

Daten

• 120.000 synthetische Bewertungen, generiert aus Zipf- (Marken, Merkmale) und Poisson-Verteilungen (Entitäten, Beziehungen), fester Seed=42.
• 6 Knotentypen: Review, Product, Reviewer, Brand, Feature, Category
• 8 Kantentypen: ABOUT, WRITTEN_BY, IN_CATEGORY, MADE_BY, HAS_POSITIVE, HAS_NEGATIVE, MENTIONS, COMPARED_WITH

Abfragen

12 Cypher-Vorlagen in 5 Kategorien: Punktabfrage (3), 1-Hop-Traversierung (2), 2-Hop-Traversierung (2), Aggregation (3), Filter (1), vollständiger Scan (1). Jede parametrisierte Abfrage läuft mit 10 verschiedenen Parameterwerten, jeweils 100 Mal, für 1.000 Messungen pro Abfrage und Datenbank.

Parameter werden aus dem gesamten ID-Raum unter Verwendung einer Zipf-gewichteten Auswahl gezogen, sodass sowohl häufige als auch seltene Elemente getestet werden.

Drei Beispiele:

Punktabfrage: Einen einzelnen Knoten anhand der indizierten ID abrufen

2-Hop-Traversierung: Von einer Marke über ihre Produkte zu deren Bewertungen wandern

Aggregation: Vollständiger Graph-Scan mit Multi-Hop-Join und Berechnung

Messung

• Timing: time.perf_counter_ns(), 500 Aufwärmabfragen, mindestens 100 Läufe pro Abfrage
• Statistik: 10.000 Bootstrap-Stichproben, 95 % CI, IQR-Ausreißer-Entfernung (3.0x Faktor). Es werden sowohl Rohdaten als auch gefilterte Daten berichtet.
• Speicher: Neo4j über JMX-Heap verwendet (VmRSS ist bedeutungslos, da die JVM vorab zuweist), FalkorDB über Redis used_memory_rss, Memgraph über /proc/{pid}/status VmRSS.

Fairness

• Gleiche Verbindungspoolgröße, Aufwärmanzahl, Cypher-Abfragen, Daten und Maschine über alle drei Datenbanken hinweg.
• Gleichzeitigkeitstest: 60-sekündige anhaltende Last bei 1, 2, 4, 8, 16 und 32 Threads mit fester pool_size=32. Abfragemix: 40 % 1-Hop-Traversierung, 30 % 2-Hop-Traversierung, 20 % Aggregation, 10 % 3-Hop-Traversierung.
  

Getestete Datenbanken

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Einschränkungen

Einzelne Maschine, einzelner Knoten pro Datenbank. Kein verteiltes oder Cluster-Benchmarking. Neo4j Enterprise-Clustering und Memgraph-Replikation liegen außerhalb des Umfangs.

Synthetische Daten mit Verteilungen, die aus echten Amazon-Bewertungen abgeleitet wurden. Möglicherweise nicht auf spezifische Produktions-Workload-Muster übertragbar.

Nicht gemessen: Festplattenpersistenz/Wiederherstellung, Volltextsuche, Graph-Algorithmen (PageRank, Community-Erkennung) und schreibintensive Arbeitslasten (>50 % Schreibvorgänge).

Unterschiedliche Treiber: Neo4j und Memgraph verwendeten den Neo4j-Python-Treiber, FalkorDB verwendete seinen eigenen. Der Overhead-Unterschied betrug <0.5ms in Single-Threaded-Tests.

Diese Forschung zitieren

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Graphdatenbank-Benchmark: Neo4j vs FalkorDB vs Memgraph}},
  year   = {2026},
  month  = apr,
  howpublished    = {\url{https://aimultiple.com/graph-databases}},
  note   = {AIMultiple. Abgerufen am 15. April 2026}
}

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenanalyst bei AIMultiple. Er entwirft und führt praxisnahe Benchmarks für KI- und LLM-Systeme durch.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten