Benchmark di database a grafo: Neo4j vs FalkorDB vs Memgraph
Abbiamo confrontato Neo4j, FalkorDB e Memgraph su un grafo sintetico derivato da 120.000 recensioni di prodotti Amazon (381K nodi, 804K archi). Abbiamo eseguito 12 modelli di query con 1.000 misurazioni ciascuno, testato l'ingestione a 6 dimensioni di batch, sostenuto un carico concorrente per 60 secondi fino a 32 thread e misurato memoria, avvio a freddo, carico di lavoro misto e impatto degli indici.
FalkorDB ha offerto un throughput più elevato rispetto a Neo4j e Memgraph a 8 thread.
Risultati del benchmark del database a grafo
Throughput concorrente
QPS (query al secondo) misura quante query di lettura il database risponde al secondo sotto carico multi-threaded sostenuto. Ogni esecuzione dura 60 secondi. Più alto è meglio.
Latenza delle query (p50)
p50 è la latenza mediana: metà di tutte le query termina più velocemente di questo valore. Più basso è meglio.
- Ricerca puntuale: Recupera un singolo nodo per ID. Le tabelle hash Redis di FalkorDB eseguono ricerche in memoria O(1), circa 3x più veloci.
- Attraversamento: Percorre da un nodo ai suoi vicini (1-hop) o ai vicini dei vicini (2-hop). FalkorDB esegue il 2-hop 2.9x più velocemente.
- Aggregazione: Conta le recensioni per marca, calcola le valutazioni medie in stelle.
- Filtro + scansione: Filtra le recensioni per valutazione in stelle sull'intero dataset.
Throughput di ingestione
Il throughput di ingestione misura quante recensioni al secondo il database può scrivere. Ogni punto del grafico è una dimensione di batch diversa: quante recensioni sono raggruppate in una singola query. Più alto è meglio.
Con dimensione batch 1, Memgraph è in testa (1.427/s). All'aumentare della dimensione del batch, FalkorDB scala rapidamente e supera Memgraph intorno al batch 500. Neo4j raggiunge un plateau a ~10.600/s indipendentemente dalla dimensione del batch. Con batch 5.000, FalkorDB raggiunge 22.784/s, 77x le sue prestazioni con batch-1.
Puoi leggere di più sulla nostra metodologia di benchmark del database a grafo.
Risultati principali
FalkorDB raggiunge 6.693 QPS a 8 thread, 6.7x Neo4j
Le strutture dati in memoria e il loop di eventi di Redis gli consentono di combinare query a bassa latenza con un elevato parallelismo. Dopo 8 thread, il throughput raggiunge un plateau perché il core single-threaded di Redis è il limite. Neo4j raggiunge il picco a 16 thread (1.010 QPS) poi cala a 32 (927 QPS), il che indica contesa dei thread.
FalkorDB si avvia a freddo in 1.1ms, 82x più veloce di Neo4j
Neo4j impiega 90ms per accettare la prima query dopo un riavvio. La prima query di riscaldamento impiega 274ms, poi servono circa 3 query per stabilizzarsi a 34ms. FalkorDB è pronto in 1.1ms, prima query a 0.4ms. In una configurazione a microservizi o serverless in cui i pod si espandono e si riducono, questa differenza conta.
Indici: 1.700x differenza su Neo4j, ~1x su FalkorDB
Senza indici, la query deep_feature_products di Neo4j impiegava 293ms. Con indici, 0.17ms. Si tratta di una differenza di 1.712x. Memgraph ha mostrato una sensibilità simile (160-898x a seconda della query). I risultati di FalkorDB sono rimasti pressoché invariati con o senza indici perché le tabelle hash di Redis funzionano già come indici impliciti.
Memoria: 415MB vs 2.668MB per lo stesso grafo
- Memgraph: 415MB
- FalkorDB: 496MB
- Neo4j: 2.668MB (heap JMX utilizzato)
La JVM di Neo4j pre-alloca 4GB all'avvio, quindi la sua memoria a livello di processo (VmRSS) è sempre ~5.2GB indipendentemente dall'uso effettivo dei dati. La metrica heap JMX è quella significativa. Il picco di 2.7GB è il numero da usare per la pianificazione della capacità.
Neo4j ha vinto l'aggregazione più pesante
FalkorDB ha avuto la latenza più bassa su 11 query su 12. L'eccezione è stata agg_feature_sentiment (raggruppa per sentiment con filtri), dove l'ottimizzatore di query di Neo4j ha prodotto un piano di esecuzione migliore: 131ms contro 152ms di FalkorDB.
Carico di lavoro misto (80% lettura, 20% scrittura)
8 thread, 60 secondi, zero errori su tutti e tre i database:
- FalkorDB: 50.223 ops (837 QPS)
- Neo4j: 44.256 ops (738 QPS)
- Memgraph: 28.040 ops (467 QPS)
Le operazioni di scrittura non hanno degradato in modo evidente le prestazioni di lettura su nessuno dei tre.
Architetture in questo benchmark
Ogni database include la propria UI di gestione. Queste schermate mostrano lo stesso dataset (16.127 nodi, 24.318 archi) caricato in tutti e tre, eseguendo la stessa query di attraversamento COMPARED_WITH.
FalkorDB
FalkorDB è un modulo grafo costruito sul key-value store in memoria di Redis. Le query sono openCypher, ma sotto ci sono tabelle hash Redis. Ecco perché le ricerche puntuali arrivano a 0.044-0.048ms.
Gli altri due database in questo benchmark hanno misurato valori 2-3x più alti sulle stesse query. Il compromesso è che il core single-threaded di Redis fa sì che il throughput concorrente smetta di scalare oltre 8 thread
Neo4j
Neo4j gira sulla JVM. La compilazione JIT fa sì che le query ripetute diventino più veloci nel tempo (riscaldamento: 274ms -> 34ms). Le pause GC influenzano la latenza di coda ma vengono rilevate dalla rimozione degli outlier IQR. L'ottimizzatore di query gestisce bene i piani di aggregazione complessi, ed è da lì che deriva la vittoria agg_feature_sentiment. Il costo è la pre-allocazione di 4GB di heap e l'overhead della GC.
Memgraph
Memgraph è scritto in C++. Nessun overhead JVM. 415MB per l'intero dataset, il più basso dei tre. Più veloce negli inserimenti individuali (1.427/s) grazie al minimo overhead per query. Ma resta indietro nel throughput concorrente (picco di 684 QPS). Compatibile con Bolt, quindi funziona con il driver Neo4j.
Metodologia del benchmark del database a grafo
Ambiente
- RunPod 8 vCPU (AMD EPYC x86_64), 32GB RAM, Ubuntu 24.04 LTS
- Installazione nativa, senza Docker. Tutti e tre i database sulla stessa macchina, connessioni localhost.
- Python 3.12.3. Sessioni persistenti per i test single-threaded, sessioni per chiamata da un pool di connessioni per i test multi-threaded.
Dati
- 120.000 recensioni sintetiche generate dalle distribuzioni Zipf (marche, caratteristiche) e Poisson (entità, relazioni), seed fisso=42.
- 6 tipi di nodo: Review, Product, Reviewer, Brand, Feature, Category
- 8 tipi di arco: ABOUT, WRITTEN_BY, IN_CATEGORY, MADE_BY, HAS_POSITIVE, HAS_NEGATIVE, MENTIONS, COMPARED_WITH
Query
12 modelli Cypher in 5 categorie: ricerca puntuale (3), attraversamento a 1-hop (2), attraversamento a 2-hop (2), aggregazione (3), filtro (1), scansione completa (1). Ogni query parametrizzata viene eseguita con 10 valori di parametro diversi, 100 volte ciascuno, per 1.000 misurazioni per query per database.
I parametri vengono campionati dall'intero spazio degli ID usando una selezione pesata Zipf, così vengono testati sia elementi popolari che rari.
Tre esempi:
Ricerca puntuale: Recupera un singolo nodo tramite ID indicizzato
Attraversamento a 2-hop: Percorre da una marca attraverso i suoi prodotti fino alle loro recensioni
Aggregazione: Scansione completa del grafo con join multi-hop e calcolo
Misurazione
- Timing:
time.perf_counter_ns(), 500 query di riscaldamento, 100 esecuzioni per query minimo - Statistiche: 10.000 campioni bootstrap, 95% CI, rimozione outlier IQR (fattore 3.0x). Vengono riportati sia i dati grezzi sia quelli filtrati.
- Memoria: Neo4j tramite heap JMX utilizzato (VmRSS non è significativo perché la JVM pre-alloca), FalkorDB tramite Redis
used_memory_rss, Memgraph tramite/proc/{pid}/statusVmRSS.
Equità
- Stessa dimensione del pool di connessioni, conteggio di warmup, query Cypher, dati e macchina per tutti e tre i database.
- Test concorrente: carico sostenuto di 60 secondi a 1, 2, 4, 8, 16 e 32 thread con pool_size fisso=32. Mix di query: 40% attraversamento a 1-hop, 30% attraversamento a 2-hop, 20% aggregazione, 10% attraversamento a 3-hop.
Database testati
Aggiungi come fonte preferitaLimitazioni
Macchina singola, nodo singolo per database. Nessun benchmarking distribuito o a cluster. Il clustering Neo4j Enterprise e la replica di Memgraph sono fuori ambito.
Dati sintetici con distribuzioni derivate da recensioni reali di Amazon. Potrebbero non corrispondere a modelli di carico di lavoro di produzione specifici.
Non misurati: persistenza/ripristino su disco, ricerca full-text, algoritmi per grafi (PageRank, rilevamento di comunità) e carichi di lavoro ad alta intensità di scrittura (>50% scritture).
Driver diversi: Neo4j e Memgraph hanno usato il driver Python di Neo4j, FalkorDB ha usato il proprio. La differenza di overhead è stata <0.5ms nei test single-threaded.
Conclusione
FalkorDB ha vinto 11 query su 12, ha raggiunto 6.693 QPS e si è avviato a freddo in 1.1ms. Per carichi di lavoro su grafi con prevalenza di lettura, è l'opzione più veloce in questo benchmark. Memgraph è l'opzione più efficiente in termini di memoria (415MB contro 2.7GB). Neo4j offre l'ecosistema più ampio: RBAC, clustering, monitoraggio e un ottimizzatore di query che gestisce i piani di aggregazione complessi meglio di entrambe le alternative.
L'architettura determina il limite. I cluster distribuiti, i grafi con oltre 1M nodi e i carichi di lavoro ad alta intensità di scrittura sono i test che potrebbero rimescolare questa classifica.
Cita questa ricerca
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Benchmark di database a grafo: Neo4j vs FalkorDB vs Memgraph}},
year = {2026},
month = apr,
howpublished = {\url{https://aimultiple.com/graph-databases}},
note = {AIMultiple. Consultato il 15 Aprile 2026}
}
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.