Comparativa de bases de datos de grafos: Neo4j vs FalkorDB vs Memgraph

actualizado el Abr 15, 2026

Realizamos pruebas comparativas de Neo4j, FalkorDB y Memgraph en un grafo sintético derivado de 120 000 reseñas de productos de Amazon (381 000 nodos, 804 000 aristas). Ejecutamos 12 plantillas de consulta con 1000 mediciones cada una, probamos la ingesta con 6 tamaños de lote, mantuvimos una carga concurrente durante 60 segundos con hasta 32 subprocesos y medimos el consumo de memoria, el arranque en frío, la carga de trabajo mixta y el impacto en los índices.

FalkorDB ofreció un rendimiento superior al de Neo4j y Memgraph con 8 hilos.

Resultados de la evaluación comparativa de bases de datos de grafos

Rendimiento simultáneo

Loading Chart

QPS (consultas por segundo) mide cuántas consultas de lectura responde la base de datos por segundo bajo una carga multihilo sostenida. Cada ejecución dura 60 segundos. Cuanto mayor sea el valor, mejor.

Latencia de consulta (p50)

p50 es la latencia media: la mitad de las consultas finalizan más rápido que este valor. Cuanto menor sea, mejor.

Búsqueda puntual: Obtenga un único nodo por ID. Las tablas hash de Redis de FalkorDB realizan búsquedas en memoria O(1), aproximadamente 3 veces más rápidas.
Recorrido: Camina desde un nodo hasta sus vecinos (1 salto) o los vecinos de los vecinos (2 saltos). FalkorDB realiza el recorrido de 2 saltos 2,9 veces más rápido.
Agregación: Se cuentan las reseñas por marca y se calcula la calificación promedio en estrellas.
Filtrar + escanear: Filtra las reseñas por calificación de estrellas en todo el conjunto de datos.

Rendimiento de ingestión

El rendimiento de ingesta mide cuántas reseñas por segundo puede procesar la base de datos. Cada punto del gráfico representa un tamaño de lote diferente: cuántas reseñas se agrupan en una sola consulta. Un valor más alto indica un mejor rendimiento.

Con un tamaño de lote de 1, Memgraph lidera (1427/s). A medida que aumenta el tamaño del lote, FalkorDB escala rápidamente y supera a Memgraph alrededor de los 500 lotes. Neo4j se estabiliza en ~10 600/s independientemente del tamaño del lote. Con 5000 lotes, FalkorDB alcanza los 22 784/s, 77 veces su rendimiento con un lote de 1.

Puedes leer más sobre nuestra metodología de evaluación comparativa de bases de datos de grafos .

Principales conclusiones

FalkorDB alcanza 6693 QPS con 8 hilos, 6,7x Neo4j

Las estructuras de datos en memoria y el bucle de eventos de Redis permiten combinar consultas de baja latencia con un alto paralelismo. Tras 8 hilos, el rendimiento se estabiliza debido a que el núcleo monohilo de Redis es el límite. Neo4j alcanza su máximo con 16 hilos (1010 consultas por segundo) y luego cae a 32 (927 consultas por segundo), lo que indica contención de hilos.

FalkorDB arranca en frío en 1,1 ms, 82 veces más rápido que Neo4j.

Neo4j tarda 90 ms en aceptar su primera consulta tras un reinicio. La primera consulta inicial se ejecuta en 274 ms, y luego tarda unas 3 consultas en estabilizarse en 34 ms. FalkorDB está listo en 1,1 ms, con la primera consulta en 0,4 ms. En una configuración de microservicios o sin servidor, donde los pods se escalan verticalmente, esta diferencia es importante.

Índices: diferencia de 1700x en Neo4j, ~1x en FalkorDB

Sin índices, la consulta deep_feature_products de Neo4j tardó 293 ms. Con índices, 0,17 ms. Esto representa una diferencia de 1712x. Memgraph mostró una sensibilidad similar (entre 160 y 898x, según la consulta). Los resultados de FalkorDB se mantuvieron prácticamente iguales con o sin índices, ya que las tablas hash de Redis funcionan como índices implícitos.

Memoria: 415 MB frente a 2668 MB para el mismo gráfico.

Memgraph: 415 MB
FalkorDB: 496 MB
Neo4j: 2668 MB (montón JMX utilizado)

La JVM de Neo4j preasigna 4 GB al arrancar, por lo que su memoria a nivel de proceso (VmRSS) siempre es de aproximadamente 5,2 GB, independientemente del uso real de datos. La métrica relevante es la del montón JMX. El pico de 2,7 GB es el valor que se debe usar para la planificación de capacidad.

Neo4j ganó la agregación más grande.

FalkorDB presentó la menor latencia en 11 de las 12 consultas. La excepción fue agg_feature_sentiment (agrupación por sentimiento con filtrado), donde el optimizador de consultas de Neo4j produjo un mejor plan de ejecución: 131 ms frente a los 152 ms de FalkorDB.

Carga de trabajo mixta (80% lectura, 20% escritura)

8 hilos, 60 segundos, cero errores en las tres bases de datos:

FalkorDB: 50.223 operaciones (837 QPS)
Neo4j: 44.256 operaciones (738 consultas por segundo)
Memgraph: 28,040 operaciones (467 QPS)

Las operaciones de escritura no degradaron de forma perceptible el rendimiento de lectura en ninguno de ellos.

Arquitecturas en este benchmark

Cada base de datos incluye su propia interfaz de administración. Estas capturas de pantalla muestran el mismo conjunto de datos (16.127 nodos, 24.318 aristas) cargado en las tres bases de datos, ejecutando la misma consulta de recorrido COMPARED_WITH.

Base de datos Falkor

FalkorDB es un módulo de grafos basado en el almacén de clave-valor en memoria de Redis. Las consultas utilizan OpenCypher, pero subyacentemente se emplean tablas hash de Redis. Por eso, las búsquedas puntuales tardan entre 0,044 y 0,048 ms.
Las otras dos bases de datos en esta prueba de rendimiento obtuvieron resultados entre 2 y 3 veces superiores en las mismas consultas. La desventaja es que el núcleo de un solo hilo de Redis implica que el rendimiento concurrente deja de escalar más allá de 8 hilos.

Navegador de FalkorDB. El panel izquierdo muestra los metadatos del grafo (6 etiquetas de nodo, 8 tipos de arista, 9 claves de propiedad). El panel de consulta ejecuta OpenCypher directamente. El uso de memoria reportado es de 4 MB solo para el índice del grafo (los datos residen en la memoria de Redis).

Neo4j

Neo4j se ejecuta en la JVM. La compilación JIT permite que las consultas repetidas se vuelvan más rápidas con el tiempo (calentamiento: 274 ms -> 34 ms). Las pausas del recolector de basura afectan la latencia de cola, pero se compensan con la eliminación de valores atípicos del rango intercuartílico. El optimizador de consultas maneja bien los planes de agregación complejos, y ahí radica la ventaja agg_feature_sentiment . El costo es la preasignación de 4 GB de memoria heap y la sobrecarga del recolector de basura.

Navegador Neo4j. La barra lateral izquierda muestra las etiquetas de los nodos (Marca, Categoría, Característica, Producto, Reseña, Reseñador), los tipos de relación y las claves de propiedad. El panel inferior muestra un recorrido COMPARED_WITH como un gráfico interactivo. Los mismos 16 127 nodos y 24 318 relaciones.

Memgraph

Memgraph está escrito en C++. No consume recursos de la JVM. Ocupa 415 MB para el conjunto de datos completo, el menor de los tres. Es el más rápido en inserciones individuales (1427/s) gracias a una mínima sobrecarga por consulta. Sin embargo, su rendimiento concurrente es inferior (684 QPS de pico). Es compatible con Bolt, por lo que funciona con el controlador Neo4j.

Esquema de grafo de Memgraph Lab. 16.127 nodos, 24.318 relaciones en 6 tipos de nodos y 8 tipos de aristas.

Metodología de evaluación comparativa de bases de datos de grafos

Ambiente

RunPod 8 vCPU (AMD EPYC x86_64), 32 GB de RAM, Ubuntu 24.04 LTS
Instalación nativa, sin Docker. Las tres bases de datos en la misma máquina, conexiones locales.
Python 3.12.3. Sesiones persistentes para pruebas de un solo hilo, sesiones por llamada desde un grupo de conexiones para pruebas de múltiples hilos.

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 nodos: Reseña, Producto, Reseñador, Marca, Característica, Categoría
8 tipos de bordes: ACERCA DE, ESCRITO POR, EN LA CATEGORÍA, HECHO POR, TIENE VALORES POSITIVOS, TIENE VALORES NEGATIVOS, MENCIONES, COMPARADO CON

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ámetros diferentes, 100 veces cada uno, para 1000 mediciones por consulta por base de datos.

Los parámetros se muestrean a partir de todo el espacio de identificadores mediante la selección ponderada de Zipf, por lo que se prueban tanto los elementos populares como los raros.

Tres ejemplos:

Búsqueda puntual : Recupera un único nodo mediante su ID indexado.

Recorrido de 2 saltos : Recorrer una marca a través de sus productos hasta llegar a sus reseñas.

Agregación : Escaneo completo del grafo con unión y cálculo de múltiples saltos.

Medición

Tiempo: time.perf_counter_ns() , 500 consultas de calentamiento, mínimo 100 ejecuciones por consulta
Estadísticas: 10 000 muestras bootstrap, IC del 95 %, eliminación de valores atípicos del rango intercuartílico (factor x3). Se presentan tanto los datos brutos como los filtrados.
Memoria: Neo4j a través del montón 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}/status VmRSS.

Justicia

El tamaño del grupo de conexiones, el número de iteraciones de calentamiento, las consultas Cypher, los datos y la máquina son los mismos en las tres bases de datos.
Prueba concurrente: carga sostenida de 60 segundos con 1, 2, 4, 8, 16 y 32 subprocesos con un pool_size fijo de 32. Combinación 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

Una sola máquina, un solo nodo por base de datos. No se realizan pruebas de rendimiento en clúster ni distribuidas. El clúster de Neo4j Enterprise y la replicación de Memgraph quedan fuera del alcance de las pruebas.

Datos sintéticos con distribuciones derivadas de reseñas reales de Amazon. Es posible que no coincidan con los patrones específicos de carga de trabajo de producción.

No se miden: persistencia/recuperación en disco, búsqueda de texto completo, algoritmos de grafos (PageRank, detección de comunidades) y cargas de trabajo con alta intensidad de escritura (>50 % de escrituras).

Controladores diferentes: Neo4j y Memgraph usaron el controlador de Python de Neo4j, mientras que FalkorDB usó el suyo propio. La diferencia de sobrecarga fue inferior a 0,5 ms en pruebas de un solo hilo.

Conclusión

FalkorDB ganó 11 de 12 consultas, alcanzó 6693 QPS y se inició en frío en 1,1 ms. Para cargas de trabajo de grafos con alta carga de lectura, es la opción más rápida en esta comparativa. Memgraph es la opción más eficiente en cuanto a memoria (415 MB frente a 2,7 GB). Neo4j ofrece el ecosistema más amplio: RBAC, clustering, monitorización y un optimizador de consultas que gestiona planes de agregación complejos mejor que cualquiera de las otras alternativas.

La arquitectura determina el límite. Los clústeres distribuidos, los gráficos de más de un millón de nodos y las cargas de trabajo con gran cantidad de escrituras son las pruebas que podrían modificar estas clasificaciones.

Ekrem Sarı

Investigador de IA

Ekrem es investigador de IA en AIMultiple, donde se centra en la automatización inteligente, las GPU, los agentes de IA y los marcos de trabajo RAG.

Ver perfil completo