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 ciascuna, testato l'ingestione a 6 dimensioni di batch, sostenuto carichi concorrenti per 60 secondi fino a 32 thread e misurato memoria, avvio a freddo, carico di lavoro misto e impatto degli indici.
FalkorDB ha fornito un throughput più elevato rispetto a Neo4j e Memgraph a 8 thread.
Risultati del benchmark dei database a grafo
Throughput concorrente
QPS (query al secondo) misura quante query di lettura il database risponde al secondo sotto carico multi-thread sostenuto. Ogni esecuzione dura 60 secondi. Più alto è, meglio è.
Latenza delle query (p50)
p50 è la latenza mediana: la 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 3 volte più veloci.
- Attraversamento: Cammina da un nodo ai suoi vicini (1-hop) o vicini-dei-vicini (2-hop). FalkorDB esegue il 2-hop 2,9 volte 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 sul grafico è una dimensione di batch diversa: quante recensioni sono raggruppate in una singola query. Più alto è, meglio è.
Alla 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 si stabilizza a circa 10.600/s indipendentemente dalla dimensione del batch. Al batch 5.000, FalkorDB raggiunge 22.784/s, 77 volte le sue prestazioni con batch-1.
Puoi leggere di più sulla nostra metodologia di benchmark dei database a grafo.
Risultati principali
FalkorDB raggiunge 6.693 QPS a 8 thread, 6,7x Neo4j
Le strutture dati in memoria e l'event loop di Redis gli consentono di combinare query a bassa latenza con elevato parallelismo. Dopo 8 thread, il throughput si stabilizza perché il core single-threaded di Redis è il limite massimo. Neo4j raggiunge il picco a 16 thread (1.010 QPS) poi scende a 32 (927 QPS), il che indica contesa tra thread.
FalkorDB si avvia a freddo in 1,1ms, 82 volte più veloce di Neo4j
Neo4j impiega 90ms per accettare la sua prima query dopo un riavvio. La prima query di riscaldamento viene eseguita a 274ms, poi ci vogliono circa 3 query per stabilizzarsi a 34ms. FalkorDB è pronto in 1,1ms, prima query a 0,4ms. In una configurazione a microservizi o serverless dove i pod scalano su e giù, quel divario conta.
Indici: differenza di 1.700x su Neo4j, ~1x su FalkorDB
Senza indici, la query deep_feature_products di Neo4j ha impiegato 293ms. Con gli indici, 0,17ms. È una differenza di 1.712x. Memgraph ha mostrato una sensibilità simile (160-898x a seconda della query). I risultati di FalkorDB sono rimasti più o meno gli stessi con o senza indici perché le tabelle hash Redis funzionano già come indici impliciti.
Memoria: 415MB contro 2.668MB per lo stesso grafo
- Memgraph: 415MB
- FalkorDB: 496MB
- Neo4j: 2.668MB (JMX heap utilizzato)
La JVM di Neo4j pre-alloca 4GB all'avvio, quindi la sua memoria a livello di processo (VmRSS) è sempre ~5,2GB indipendentemente dall'utilizzo effettivo dei dati. La metrica JMX heap è quella significativa. Il picco di 2,7GB è il numero da utilizzare per la pianificazione della capacità.
Neo4j ha vinto l'aggregazione più pesante
FalkorDB ha avuto la latenza più bassa su 11 delle 12 query. L'eccezione è stata agg_feature_sentiment (raggruppamento per sentiment con filtraggio), dove l'ottimizzatore di query di Neo4j ha prodotto un piano di esecuzione migliore: 131ms contro i 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 operazioni (837 QPS)
- Neo4j: 44.256 operazioni (738 QPS)
- Memgraph: 28.040 operazioni (467 QPS)
Le operazioni di scrittura non hanno degradato in modo evidente le prestazioni di lettura su nessuno di essi.
Architetture in questo benchmark
Ogni database fornisce la propria interfaccia di gestione. Questi screenshot 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 datastore chiave-valore 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-3 volte superiori sulle stesse query. Il compromesso è che il core single-threaded di Redis significa che il throughput concorrente smette di scalare oltre 8 thread
Neo4j
Neo4j funziona sulla JVM. La compilazione JIT significa che le query ripetute diventano più veloci nel tempo (riscaldamento: 274ms -> 34ms). Le pause GC influenzano la latenza di coda ma vengono catturate dalla rimozione degli outlier IQR. L'ottimizzatore di query gestisce bene i piani di aggregazione complessi, ed è da lì che arriva la vittoria su agg_feature_sentiment. Il costo è la pre-allocazione di 4GB di heap e l'overhead GC.
Memgraph
Memgraph è scritto in C++. Nessun overhead JVM. 415MB per l'intero dataset, il più basso dei tre. Il 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.
Aggiungi come fonte preferitaMetodologia del benchmark dei 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 connection pool per i test multi-threaded.
Dati
- 120.000 recensioni sintetiche generate da distribuzioni Zipf (marche, caratteristiche) e Poisson (entità, relazioni), seed fisso=42.
- 6 tipi di nodi: Review, Product, Reviewer, Brand, Feature, Category
- 8 tipi di archi: 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 1-hop (2), attraversamento 2-hop (2), aggregazione (3), filtro (1), scansione completa (1). Ogni query parametrizzata viene eseguita con 10 diversi valori di parametro, 100 volte ciascuna, per 1.000 misurazioni per query per database.
I parametri sono campionati dall'intero spazio degli ID utilizzando una selezione pesata Zipf, in modo che siano testati sia elementi popolari che rari.
Tre esempi:
Ricerca puntuale: Recupera un singolo nodo per ID indicizzato
Attraversamento 2-hop: Cammina da una marca attraverso i suoi prodotti fino alle loro recensioni
Aggregazione: Scansione completa del grafo con join multi-hop e calcolo
Misurazione
- Tempistica:
time.perf_counter_ns(), 500 query di riscaldamento, 100 esecuzioni per query minime - Statistiche: 10.000 campioni bootstrap, IC 95%, rimozione outlier IQR (fattore 3,0x). Vengono riportati sia i dati grezzi che quelli filtrati.
- Memoria: Neo4j tramite JMX heap utilizzato (VmRSS non è significativo perché JVM pre-alloca), FalkorDB tramite Redis
used_memory_rss, Memgraph tramite/proc/{pid}/statusVmRSS.
Equità
- Stessa dimensione del connection pool, conteggio di riscaldamento, query Cypher, dati e macchina su tutti e tre i database.
- Test concorrente: carico sostenuto di 60 secondi a 1, 2, 4, 8, 16 e 32 thread con un pool_size fisso=32. Mix di query: 40% attraversamento 1-hop, 30% attraversamento 2-hop, 20% aggregazione, 10% attraversamento 3-hop.
Database testati
Limitazioni
Singola macchina, singolo nodo per database. Nessun benchmark distribuito o a cluster. Il clustering Enterprise di Neo4j e la replica di Memgraph sono al di fuori dello scopo.
Dati sintetici con distribuzioni derivate da recensioni Amazon reali. Potrebbero non corrispondere a modelli specifici di carico di lavoro in produzione.
Non misurato: persistenza/ripristino su disco, ricerca full-text, algoritmi per grafi (PageRank, rilevamento di comunità) e carichi di lavoro con prevalenza di scrittura (>50% scritture).
Driver diversi: Neo4j e Memgraph hanno utilizzato il driver Python Neo4j, FalkorDB ha utilizzato il proprio. La differenza di overhead è stata <0,5ms nei test single-threaded.
Conclusione
FalkorDB ha vinto 11 delle 12 query, ha raggiunto 6.693 QPS e si è avviato a freddo in 1,1ms. Per carichi di lavoro a grafo 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 meglio piani di aggregazione complessi rispetto a entrambe le alternative.
L'architettura determina il limite massimo. Cluster distribuiti, grafi con oltre 1 milione di nodi e carichi di lavoro con prevalenza di scrittura sono i test che potrebbero ridistribuire queste classifiche.
Cita questa ricerca
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{sar2026,
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.