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

Comparamos 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 ingesta con 6 tamaños de lote, mantuvimos carga concurrente durante 60 segundos con hasta 32 hilos, y medimos memoria, arranque en frío, carga de trabajo mixta e impacto de índices.

FalkorDB proporcionó un mayor rendimiento que Neo4j y Memgraph con 8 hilos.

Resultados del benchmark de bases 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 de múltiples hilos. Cada ejecución dura 60 segundos. Cuanto más alto, mejor.

Latencia de consulta (p50)

p50 es la latencia media: la mitad de todas las consultas terminan más rápido que este valor. Cuanto más bajo, mejor.

• Búsqueda puntual: Obtener un único nodo por ID. Las tablas hash de Redis de FalkorDB realizan búsquedas en memoria O(1), aproximadamente 3x más rápido.
• Recorrido: Caminar desde un nodo a sus vecinos (1 salto) o vecinos de vecinos (2 saltos). FalkorDB realiza el recorrido de 2 saltos 2.9x más rápido.
• Agregación: Contar reseñas por marca, calcular valoraciones promedio de estrellas.
• Filtro + escaneo: Filtrar reseñas por valoración de estrellas en todo el dataset.

Rendimiento de ingesta

El rendimiento de ingesta mide cuántas reseñas por segundo puede escribir la base de datos. Cada punto del gráfico representa un tamaño de lote diferente: cuántas reseñas se agrupan en una única consulta. Cuanto más alto, mejor.

Con un tamaño de lote de 1, Memgraph lidera (1.427/s). A medida que aumenta el tamaño del lote, FalkorDB escala pronunciadamente y supera a Memgraph alrededor del lote 500. Neo4j se estanca en aproximadamente 10.600/s independientemente del tamaño del lote. Con un lote de 5.000, FalkorDB alcanza 22.784/s, 77x su rendimiento con lote de 1.

Puede leer más sobre nuestra metodología de benchmark de bases de datos de grafos.

Hallazgos clave

FalkorDB alcanza 6.693 QPS con 8 hilos, 6.7x Neo4j

Las estructuras de datos en memoria y el bucle de eventos de Redis le permiten combinar consultas de baja latencia con alto paralelismo. Después de 8 hilos, el rendimiento se estanca porque el núcleo de un solo hilo de Redis es el límite. Neo4j alcanza su pico con 16 hilos (1.010 QPS) y luego cae con 32 (927 QPS), lo que apunta a contención de hilos.

FalkorDB arranca en frío en 1.1ms, 82x 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, y luego tarda aproximadamente 3 consultas en estabilizarse en 34ms. FalkorDB está listo en 1.1ms, primera consulta en 0.4ms. En una configuración de microservicio o serverless donde los pods aumentan y disminuyen, esa diferencia importa.

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

Sin índices, la consulta deep_feature_products de Neo4j tardó 293ms. Con índices, 0.17ms. Esa es una diferencia de 1.712x. Memgraph mostró una sensibilidad similar (160-898x 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 frente a 2.668MB para el mismo grafo

• Memgraph: 415MB
• FalkorDB: 496MB
• Neo4j: 2.668MB (heap de JMX utilizado)

La JVM de Neo4j preasigna 4GB al inicio, por lo que su memoria a nivel de proceso (VmRSS) siempre es de aproximadamente 5.2GB independientemente del uso real de datos. La métrica de heap de 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 mejor plan de ejecución: 131ms frente a los 152ms 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 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 este benchmark

Cada base de datos incluye su propia interfaz de gestión. Estas capturas de pantalla muestran el mismo dataset (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 grafos construido sobre el almacén clave-valor en memoria de Redis. Las consultas son openCypher, pero por debajo son tablas hash de Redis. Por eso las búsquedas puntuales aterrizan en 0.044-0.048ms.
Las otras dos bases de datos de este benchmark midieron 2-3x más alto en las mismas consultas. El compromiso 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 aceleran con el tiempo (calentamiento: 274ms -> 34ms). Las pausas del GC afectan la latencia de cola, pero se capturan mediante la eliminación de valores atípicos por IQR. El optimizador de consultas maneja bien los planes de agregación complejos, y de ahí proviene la victoria de agg_feature_sentiment. El costo es la preasignación de heap de 4GB y la sobrecarga del GC.

Memgraph

Memgraph está escrito en C++. Sin sobrecarga de JVM. 415MB para el dataset completo, el más bajo de los tres. Es el más rápido en inserciones individuales (1.427/s) gracias a la mínima sobrecarga por consulta. Pero se queda atrás en rendimiento concurrente (pico de 684 QPS). Compatible con Bolt, por lo que funciona con el driver de Neo4j.

Metodología del benchmark de bases 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 a localhost.
• Python 3.12.3. Sesiones persistentes para pruebas de un solo hilo, sesiones por llamada desde un pool 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: Review, Product, Reviewer, Brand, Feature, Category
• 8 tipos de aristas: ABOUT, WRITTEN_BY, IN_CATEGORY, MADE_BY, HAS_POSITIVE, HAS_NEGATIVE, MENTIONS, COMPARED_WITH

Consultas

12 plantillas de 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 uno, para 1.000 mediciones por consulta por base de datos.

Los parámetros se muestrean del espacio completo de IDs utilizando una selección ponderada por Zipf, de modo que se prueban tanto elementos populares como raros.

Tres ejemplos:

Búsqueda puntual: Obtener un único nodo por ID indexado

Recorrido de 2 saltos: Caminar desde una marca a través de sus productos hasta sus reseñas

Agregación: Escaneo completo del grafo con unión multi-salto y computación

Medición

• Temporización: time.perf_counter_ns(), 500 consultas de calentamiento, 100 ejecuciones por consulta como mínimo
• Estadísticas: 10.000 muestras bootstrap, 95 % CI, eliminación de valores atípicos por IQR (factor 3.0x). Se reportan tanto los datos brutos como los filtrados.
• Memoria: Neo4j mediante heap de JMX utilizado (VmRSS no tiene sentido porque la JVM preasigna), FalkorDB mediante Redis used_memory_rss, Memgraph mediante /proc/{pid}/status VmRSS.

Equidad

• Mismo tamaño de pool de conexiones, cantidad 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

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Limitaciones

Máquina única, nodo único por base de datos. Sin benchmarking distribuido ni de clúster. El clustering 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 que no coincidan con patrones de carga de trabajo de producción específicos.

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

Drivers diferentes: Neo4j y Memgraph utilizaron el driver Python de Neo4j, FalkorDB utilizó el suyo propio. La diferencia de sobrecarga fue <0.5ms en pruebas de un solo hilo.

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{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Comparativa de bases 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}
}

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA y analista de datos en AIMultiple. Diseña y ejecuta benchmarks prácticos para sistemas de IA y LLM.

Ver perfil completo

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.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario