Benchmark de bases de données graphiques: Neo4j vs FalkorDB vs Memgraph
Nous avons comparé Neo4j, FalkorDB et Memgraph sur un graphe synthétique dérivé de 120 000 avis produits Amazon (381K nœuds, 804K arêtes). Nous avons exécuté 12 modèles de requêtes avec 1 000 mesures chacun, testé l’ingestion à 6 tailles de lots, maintenu une charge simultanée pendant 60 secondes jusqu’à 32 threads, et mesuré la mémoire, le démarrage à froid, la charge mixte et l’impact des index.
FalkorDB a fourni un débit supérieur à Neo4j et Memgraph à 8 threads.
Résultats du benchmark des bases de données graphiques
Débit concurrent
Le QPS (requêtes par seconde) mesure combien de requêtes de lecture la base de données traite par seconde sous une charge multi-thread soutenue. Chaque exécution dure 60 secondes. Plus la valeur est élevée, mieux c’est.
Latence des requêtes (p50)
Le p50 est la latence médiane : la moitié des requêtes se terminent plus rapidement que cette valeur. Plus elle est basse, mieux c’est.
- Point lookup : Récupère un seul nœud par ID. Les tables de hachage Redis de FalkorDB effectuent des recherches en mémoire en O(1), environ 3x plus rapides.
- Traversal : Parcourt depuis un nœud vers ses voisins (1-hop) ou les voisins des voisins (2-hop). FalkorDB effectue le 2-hop 2.9x plus rapidement.
- Agrégation : Compte les avis par marque, calcule les notes moyennes en étoiles.
- Filtre + scan : Filtre les avis par note en étoiles sur l’ensemble du dataset.
Débit d’ingestion
Le débit d’ingestion mesure combien d’avis par seconde la base de données peut écrire. Chaque point du graphique correspond à une taille de lot différente : combien d’avis sont regroupés dans une seule requête. Plus la valeur est élevée, mieux c’est.
À la taille de lot 1, Memgraph est en tête (1 427/s). À mesure que la taille de lot augmente, FalkorDB monte fortement et dépasse Memgraph autour du lot 500. Neo4j plafonne à environ 10 600/s quelle que soit la taille de lot. Au lot 5 000, FalkorDB atteint 22 784/s, soit 77x sa performance au lot 1.
Vous pouvez en savoir plus sur la méthodologie de notre benchmark des bases de données graphiques.
Principaux résultats
FalkorDB atteint 6 693 QPS à 8 threads, 6.7x Neo4j
Les structures de données en mémoire et la boucle d’événements de Redis lui permettent de combiner des requêtes à faible latence avec un parallélisme élevé. Après 8 threads, le débit plafonne car le cœur mono-thread de Redis constitue la limite. Neo4j atteint un pic à 16 threads (1 010 QPS) puis baisse à 32 (927 QPS), ce qui indique une contention des threads.
FalkorDB démarre à froid en 1.1ms, 82x plus rapide que Neo4j
Neo4j met 90ms pour accepter sa première requête après un redémarrage. La première requête de chauffe s’exécute en 274ms, puis il faut environ 3 requêtes pour se stabiliser à 34ms. FalkorDB est prêt en 1.1ms, première requête en 0.4ms. Dans une configuration microservice ou serverless où les pods montent et descendent en charge, cet écart compte.
Index : 1 700x de différence sur Neo4j, ~1x sur FalkorDB
Sans index, la requête deep_feature_products de Neo4j a pris 293ms. Avec index, 0.17ms. C’est une différence de 1 712x. Memgraph a montré une sensibilité similaire (160-898x selon la requête). Les résultats de FalkorDB sont restés à peu près les mêmes avec ou sans index car les tables de hachage Redis fonctionnent déjà comme des index implicites.
Mémoire : 415MB vs 2 668MB pour le même graphe
- Memgraph : 415MB
- FalkorDB : 496MB
- Neo4j : 2 668MB (JMX heap utilisée)
La JVM de Neo4j pré-alloue 4GB au démarrage, donc sa mémoire au niveau du processus (VmRSS) est toujours d’environ 5.2GB quelle que soit l’utilisation réelle des données. La métrique de heap JMX est celle qui compte. Le pic de 2.7GB est le chiffre à utiliser pour la planification des capacités.
Neo4j a remporté l’agrégation la plus lourde
FalkorDB a eu la latence la plus faible sur 11 des 12 requêtes. L’exception était agg_feature_sentiment (groupement par sentiment avec filtrage), où l’optimiseur de requêtes de Neo4j a produit un meilleur plan d’exécution : 131ms contre 152ms pour FalkorDB.
Charge mixte (80 % lecture, 20 % écriture)
8 threads, 60 secondes, zéro erreur sur les trois bases de données :
- FalkorDB : 50 223 ops (837 QPS)
- Neo4j : 44 256 ops (738 QPS)
- Memgraph : 28 040 ops (467 QPS)
Les opérations d’écriture n’ont pas dégradé de manière notable les performances en lecture sur aucune des trois.
Architectures dans ce benchmark
Chaque base de données est livrée avec sa propre interface d’administration. Ces captures d’écran montrent le même dataset (16 127 nœuds, 24 318 arêtes) chargé dans les trois, exécutant la même requête de traversal COMPARED_WITH.
FalkorDB
FalkorDB est un module de graphe construit sur le stockage clé-valeur en mémoire de Redis. Les requêtes sont en openCypher, mais en dessous ce sont des tables de hachage Redis. C’est pourquoi les recherches ponctuelles atterrissent entre 0.044 et 0.048ms.
Les deux autres bases de données de ce benchmark ont mesuré des valeurs 2 à 3x supérieures sur les mêmes requêtes. Le compromis est que le cœur mono-thread de Redis signifie que le débit concurrent cesse d’évoluer après 8 threads
Neo4j
Neo4j fonctionne sur la JVM. La compilation JIT signifie que les requêtes répétées deviennent plus rapides au fil du temps (chauffe : 274ms -> 34ms). Les pauses GC affectent la latence de queue mais sont détectées par la suppression des valeurs aberrantes IQR. L’optimiseur de requêtes gère bien les plans d’agrégation complexes, et c’est de là que vient la victoire agg_feature_sentiment. Le coût est la pré-allocation de 4GB de heap et la surcharge GC.
Memgraph
Memgraph est écrit en C++. Aucune surcharge JVM. 415MB pour l’ensemble du dataset, le plus bas des trois. Le plus rapide pour les insertions individuelles (1 427/s) grâce à une surcharge minimale par requête. Mais il est en retrait sur le débit concurrent (684 QPS en pic). Compatible Bolt, il fonctionne donc avec le driver Neo4j.
Méthodologie du benchmark des bases de données graphiques
Environnement
- RunPod 8 vCPU (AMD EPYC x86_64), 32GB RAM, Ubuntu 24.04 LTS
- Installation native, sans Docker. Les trois bases de données sur la même machine, connexions localhost.
- Python 3.12.3. Sessions persistantes pour les tests mono-thread, sessions par appel depuis un pool de connexions pour les tests multi-threads.
Données
- 120 000 avis synthétiques générés à partir de distributions Zipf (marques, caractéristiques) et Poisson (entités, relations), seed fixe=42.
- 6 types de nœuds : Review, Product, Reviewer, Brand, Feature, Category
- 8 types d’arêtes : ABOUT, WRITTEN_BY, IN_CATEGORY, MADE_BY, HAS_POSITIVE, HAS_NEGATIVE, MENTIONS, COMPARED_WITH
Requêtes
12 modèles Cypher répartis en 5 catégories : point lookup (3), traversal 1-hop (2), traversal 2-hop (2), agrégation (3), filtre (1), scan complet (1). Chaque requête paramétrée s’exécute avec 10 valeurs de paramètres différentes, 100 fois chacune, pour 1 000 mesures par requête et par base de données.
Les paramètres sont échantillonnés dans l’espace complet des ID à l’aide d’une sélection pondérée par Zipf, afin de tester aussi bien les éléments populaires que rares.
Trois exemples :
Point lookup : Récupère un seul nœud par ID indexé
Traversal 2-hop : Parcourt depuis une marque à travers ses produits jusqu’à leurs avis
Agrégation : Scan complet du graphe avec jointure multi-hop et calcul
Mesure
- Chronométrage :
time.perf_counter_ns(), 500 requêtes de chauffe, 100 exécutions par requête minimum - Statistiques : 10 000 échantillons bootstrap, 95 % IC, suppression des valeurs aberrantes IQR (facteur 3.0x). Les données brutes et filtrées sont toutes deux rapportées.
- Mémoire : Neo4j via JMX heap utilisée (VmRSS n’a pas de sens car la JVM pré-alloue), FalkorDB via Redis
used_memory_rss, Memgraph via/proc/{pid}/statusVmRSS.
Équité
- Même taille de pool de connexions, nombre de requêtes de chauffe, requêtes Cypher, données et machine sur les trois bases de données.
- Test concurrent : charge soutenue de 60 secondes à 1, 2, 4, 8, 16 et 32 threads avec un pool_size fixe=32. Mélange de requêtes : 40 % traversal 1-hop, 30 % traversal 2-hop, 20 % agrégation, 10 % traversal 3-hop.
Bases de données testées
Ajouter comme source préféréeLimites
Machine unique, nœud unique par base de données. Pas de benchmark distribué ni de cluster. Le clustering Neo4j Enterprise et la réplication Memgraph sont hors périmètre.
Données synthétiques avec des distributions dérivées d’avis Amazon réels. Peuvent ne pas correspondre à des modèles de charge de production spécifiques.
Non mesurés : persistance/récupération sur disque, recherche plein texte, algorithmes de graphe (PageRank, détection de communautés) et charges de travail à dominante écriture (>50 % d’écritures).
Drivers différents : Neo4j et Memgraph ont utilisé le driver Python Neo4j, FalkorDB le sien. La différence de surcharge était <0.5ms dans les tests mono-thread.
Conclusion
FalkorDB a remporté 11 des 12 requêtes, atteint 6 693 QPS et démarré à froid en 1.1ms. Pour les charges de travail graphiques à dominante lecture, c’est l’option la plus rapide de ce benchmark. Memgraph est l’option la plus économe en mémoire (415MB contre 2.7GB). Neo4j offre l’écosystème le plus large : RBAC, clustering, monitoring et un optimiseur de requêtes qui gère mieux les plans d’agrégation complexes que les deux alternatives.
L’architecture détermine le plafond. Les clusters distribués, les graphes de plus de 1M nœuds et les charges à dominante écriture sont les tests qui pourraient rebattre ces classements.
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Benchmark de bases de données graphiques: Neo4j vs FalkorDB vs Memgraph}},
year = {2026},
month = apr,
howpublished = {\url{https://aimultiple.com/graph-databases}},
note = {AIMultiple. Consulté le 15 Avril 2026}
}
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.