Prueba de referencia de base de datos de grafos: Neo4j vs FalkorDB vs Memgraph
Realizamos pruebas de referencia de Neo4j, FalkorDB y Memgraph en un grafo sintético derivado de 120,000 reseñas de productos de Amazon (381K nodos, 804K aristas). Ejecutamos 12 plantillas de consultas con 1,000 mediciones cada una, probamos la ingestión en 6 tamaños de lote, mantenemos carga concurrente durante 60 segundos con hasta 32 hilos, y medimos memoria, inicio en frío, carga mixta e impacto de índices.
FalkorDB entregó un mayor rendimiento que Neo4j y Memgraph con 8 hilos.
Resultados de la prueba de referencia de base de datos de grafos
Rendimiento concurrente
QPS (consultas por segundo) mide cuántas consultas de lectura responde la base de datos por segundo bajo carga sostenida multihilo. Cada ejecución dura 60 segundos. Más alto es mejor.
Latencia de consulta (p50)
p50 es la latencia mediana: la mitad de todas las consultas terminan más rápido que este valor. Más bajo es mejor.
- Búsqueda puntual: Obtener un solo nodo por ID. Las tablas hash de Redis de FalkorDB realizan búsquedas en memoria O(1), aproximadamente 3 veces más rápido.
- Recorrido: Caminar desde un nodo a sus vecinos (1 salto) o vecinos de vecinos (2 saltos). FalkorDB realiza 2 saltos en 2.9 veces más rápido.
- Agregación: Contar reseñas por marca, calcular calificaciones promedio de estrellas.
- Filtrar + escanear: Filtrar reseñas por calificación de estrellas en todo el conjunto de datos.
Rendimiento de ingestión
El rendimiento de ingestión mide cuántas reseñas por segundo puede escribir la base de datos. Cada punto en el gráfico es un tamaño de lote diferente: cuántas reseñas se agrupan en una sola consulta. Más alto es mejor.
Con tamaño de lote 1, Memgraph lidera (1,427/s). A medida que aumenta el tamaño del lote, FalkorDB escala rápidamente y cruza a Memgraph alrededor del lote 500. Neo4j se estabiliza en ~10,600/s independientemente del tamaño del lote. Con lote 5,000, FalkorDB alcanza 22,784/s, 77 veces su rendimiento de lote 1.
Puede leer más sobre nuestra prueba de referencia de base de datos de grafos metodología.
Hallazgos clave
FalkorDB alcanza 6,693 QPS con 8 hilos, 6.7x Neo4j
Las estructuras de datos en memoria de Redis y su bucle de eventos permiten combinar consultas de baja latencia con alto paralelismo. Después de 8 hilos, el rendimiento se estabiliza porque el núcleo de un solo hilo de Redis es el límite. Neo4j alcanza su punto máximo con 16 hilos (1,010 QPS) y luego cae con 32 (927 QPS), lo que indica contención de hilos.
FalkorDB inicia en frío en 1.1ms, 82 veces más rápido que Neo4j
Neo4j tarda 90ms en aceptar su primera consulta después de un reinicio. La primera consulta de calentamiento se ejecuta en 274ms, luego toma unas 3 consultas estabilizarse hasta 34ms. FalkorDB está listo en 1.1ms, primera consulta en 0.4ms. En una configuración de microservicio o serverless donde los pods se escalan hacia arriba y hacia abajo, esa diferencia importa.
Índices: 1,700 veces de diferencia en Neo4j, ~1x en FalkorDB
Sin índices, la consulta de Neo4j deep_feature_products tardó 293ms. Con índices, 0.17ms. Esa es una diferencia de 1,712 veces. Memgraph mostró una sensibilidad similar (160-898 veces dependiendo de la consulta). Los resultados de FalkorDB se mantuvieron aproximadamente iguales con o sin índices porque las tablas hash de Redis ya funcionan como índices implícitos.
Memoria: 415MB vs 2,668MB para el mismo grafo
- Memgraph: 415MB
- FalkorDB: 496MB
- Neo4j: 2,668MB (heap JMX usado)
La JVM de Neo4j preasigna 4GB al inicio, por lo que su memoria a nivel de proceso (VmRSS) es siempre ~5.2GB independientemente del uso real de datos. La métrica de heap JMX es la significativa. El pico de 2.7GB es el número a usar para la planificación de capacidad.
Neo4j ganó la agregación más pesada
FalkorDB tuvo la latencia más baja en 11 de 12 consultas. La excepción fue agg_feature_sentiment (agrupar por sentimiento con filtrado), donde el optimizador de consultas de Neo4j produjo un plan de ejecución mejor: 131ms vs 152ms de FalkorDB.
Carga mixta (80% lectura, 20% escritura)
8 hilos, 60 segundos, cero errores en las tres bases de datos:
- FalkorDB: 50,223 ops (837 QPS)
- Neo4j: 44,256 ops (738 QPS)
- Memgraph: 28,040 ops (467 QPS)
Las operaciones de escritura no degradaron notablemente el rendimiento de lectura en ninguna de ellas.
Arquitecturas en esta prueba de referencia
Cada base de datos incluye su propia interfaz de gestión. Estas capturas de pantalla muestran el mismo conjunto de datos (16,127 nodos, 24,318 aristas) cargado en las tres, ejecutando la misma consulta de recorrido COMPARED_WITH.
FalkorDB
FalkorDB es un módulo de grafo construido sobre el almacén de claves-valor en memoria de Redis. Las consultas son openCypher, pero debajo son tablas hash de Redis. Por eso las búsquedas puntuales se sitúan en 0.044-0.048ms.
Las otras dos bases de datos en esta prueba midieron 2-3 veces más alto en las mismas consultas. La compensación es que el núcleo de un solo hilo de Redis significa que el rendimiento concurrente deja de escalar más allá de 8 hilos
Neo4j
Neo4j se ejecuta en la JVM. La compilación JIT significa que las consultas repetidas se vuelven más rápidas con el tiempo (calentamiento: 274ms -> 34ms). Las pausas de GC afectan la latencia de cola pero son detectadas por la eliminación de valores atípicos IQR. El optimizador de consultas maneja bien planes de agregación complejos, y es de ahí donde proviene la victoria de agg_feature_sentiment. El costo es la preasignación de 4GB de heap y la sobrecarga de GC.
Memgraph
Memgraph está escrito en C++. Sin sobrecarga de JVM. 415MB para el conjunto de datos completo, el más bajo de los tres. El más rápido en inserciones individuales (1,427/s) gracias a una sobrecarga mínima por consulta. Pero se queda atrás en rendimiento concurrente (684 QPS pico). Compatible con Bolt, por lo que funciona con el controlador de Neo4j.
Añadir como fuente preferidaMetodología de prueba de referencia de base de datos de grafos
Entorno
- RunPod 8 vCPU (AMD EPYC x86_64), 32GB RAM, Ubuntu 24.04 LTS
- Instalación nativa, sin Docker. Las tres bases de datos en la misma máquina, conexiones localhost.
- Python 3.12.3. Sesiones persistentes para pruebas de un solo hilo, sesiones por llamada desde un pool de conexiones para pruebas multihilo.
Datos
- 120,000 reseñas sintéticas generadas a partir de distribuciones Zipf (marcas, características) y Poisson (entidades, relaciones), semilla fija=42.
- 6 tipos de nodo: Reseña, Producto, Revisor, Marca, Característica, Categoría
- 8 tipos de arista: ABOUT, WRITTEN_BY, IN_CATEGORY, MADE_BY, HAS_POSITIVE, HAS_NEGATIVE, MENTIONS, COMPARED_WITH
Consultas
12 plantillas Cypher en 5 categorías: búsqueda puntual (3), recorrido de 1 salto (2), recorrido de 2 saltos (2), agregación (3), filtro (1), escaneo completo (1). Cada consulta parametrizada se ejecuta con 10 valores de parámetro diferentes, 100 veces cada una, para 1,000 mediciones por consulta por base de datos.
Los parámetros se muestrean del espacio completo de IDs usando selección ponderada por Zipf, por lo que se prueban tanto elementos populares como raros.
Tres ejemplos:
Búsqueda puntual: Obtener un solo nodo por ID indexado
Recorrido de 2 saltos: Caminar desde una marca a través de sus productos hasta sus reseñas
Aggregación: Escaneo completo del grafo con unión de múltiples saltos y cálculo
Medición
- Tiempo:
time.perf_counter_ns(), 500 consultas de calentamiento, mínimo 100 ejecuciones por consulta - Estadísticas: 10,000 muestras de bootstrap, IC 95%, eliminación de valores atípicos IQR (factor 3.0x). Se reportan tanto datos crudos como filtrados.
- Memoria: Neo4j a través de heap JMX usado (VmRSS no tiene sentido porque la JVM preasigna), FalkorDB a través de Redis
used_memory_rss, Memgraph a través de/proc/{pid}/statusVmRSS.
Equidad
- Mismo tamaño de pool de conexiones, conteo de calentamiento, consultas Cypher, datos y máquina en las tres bases de datos.
- Prueba concurrente: carga sostenida de 60 segundos con 1, 2, 4, 8, 16 y 32 hilos con un pool_size=32 fijo. Mezcla de consultas: 40% recorrido de 1 salto, 30% recorrido de 2 saltos, 20% agregación, 10% recorrido de 3 saltos.
Bases de datos probadas
Limitaciones
Máquina única, nodo único por base de datos. Sin pruebas de referencia distribuidas o de clúster. El clúster de Neo4j Enterprise y la replicación de Memgraph están fuera del alcance.
Datos sintéticos con distribuciones derivadas de reseñas reales de Amazon. Puede no coincidir con patrones de carga de trabajo de producción específicos.
No medido: persistencia/recuperación en disco, búsqueda de texto completo, algoritmos de grafos (PageRank, detección de comunidades) y cargas de trabajo pesadas en escritura (>50% escrituras).
Controladores diferentes: Neo4j y Memgraph usaron el controlador Python de Neo4j, FalkorDB usó el suyo. La diferencia de sobrecarga fue <0.5ms en pruebas de un solo hilo.
Conclusión
FalkorDB ganó 11 de 12 consultas, alcanzó 6,693 QPS e inició en frío en 1.1ms. Para cargas de trabajo de grafos pesadas en lectura, es la opción más rápida en esta prueba de referencia. Memgraph es la opción más eficiente en memoria (415MB vs 2.7GB). Neo4j ofrece el ecosistema más amplio: RBAC, clúster, monitoreo y un optimizador de consultas que maneja planes de agregación complejos mejor que cualquier alternativa.
La arquitectura determina el límite. Clústeres distribuidos, grafos de 1M+ nodos y cargas de trabajo pesadas en escritura son las pruebas que podrían reordenar estos rankings.
Cita esta investigación
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{sar2026,
author = {Sarı, Ekrem},
title = {{Prueba de referencia de base de datos de grafos: Neo4j vs FalkorDB vs Memgraph}},
year = {2026},
month = apr,
howpublished = {\url{https://aimultiple.com/graph-databases}},
note = {AIMultiple. Recuperado el 15 de Abril de 2026}
}
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.