Benchmark de banco de dados de grafos: Neo4j vs FalkorDB vs Memgraph

Comparamos Neo4j, FalkorDB e Memgraph em um grafo sintético derivado de 120.000 avaliações de produtos da Amazon (381K nós, 804K arestas). Executamos 12 modelos de consulta com 1.000 medições cada, testamos a ingestão em 6 tamanhos de lote, sustentamos carga concorrente por 60 segundos em até 32 threads e medimos memória, partida a frio, carga de trabalho mista e impacto de índices.

FalkorDB entregou maior vazão do que Neo4j e Memgraph com 8 threads.

Resultados do benchmark de banco de dados de grafos

Vazão concorrente

QPS (consultas por segundo) mede quantas consultas de leitura o banco de dados responde por segundo sob carga concorrente sustentada e multithread. Cada execução dura 60 segundos. Quanto maior, melhor.

Latência de consulta (p50)

p50 é a latência mediana: metade de todas as consultas termina mais rápido que esse valor. Quanto menor, melhor.

• Pesquisa pontual: Busca um único nó por ID. As tabelas hash do Redis do FalkorDB fazem pesquisas em memória O(1), aproximadamente 3x mais rápidas.
• Travessia: Percorre de um nó para seus vizinhos (1 salto) ou vizinhos dos vizinhos (2 saltos). FalkorDB faz 2 saltos 2.9x mais rápido.
• Agregação: Conta avaliações por marca e calcula classificações médias de estrelas.
• Filtro + varredura: Filtra avaliações por classificação de estrelas em todo o dataset.

Vazão de ingestão

A vazão de ingestão mede quantas avaliações por segundo o banco de dados consegue gravar. Cada ponto no gráfico é um tamanho de lote diferente: quantas avaliações são agrupadas em uma única consulta. Quanto maior, melhor.

No tamanho de lote 1, Memgraph lidera (1.427/s). À medida que o tamanho do lote aumenta, FalkorDB cresce acentuadamente e ultrapassa Memgraph em torno do lote 500. Neo4j estabiliza em ~10.600/s independentemente do tamanho do lote. No lote 5.000, FalkorDB atinge 22.784/s, 77x seu desempenho do lote 1.

Você pode ler mais sobre a metodologia do nosso benchmark de banco de dados de grafos.

Principais descobertas

FalkorDB atinge 6.693 QPS com 8 threads, 6.7x Neo4j

As estruturas de dados em memória do Redis e seu loop de eventos permitem combinar consultas de baixa latência com alto paralelismo. Depois de 8 threads, a vazão se estabiliza porque o núcleo de thread única do Redis é o limite. Neo4j atinge pico em 16 threads (1.010 QPS) e depois cai em 32 (927 QPS), o que indica contenção de threads.

FalkorDB parte a frio em 1.1ms, 82x mais rápido que Neo4j

Neo4j leva 90ms para aceitar a primeira consulta após uma reinicialização. A primeira consulta de aquecimento roda em 274ms, depois leva cerca de 3 consultas para estabilizar em 34ms. FalkorDB fica pronto em 1.1ms, primeira consulta em 0.4ms. Em uma configuração de microsserviço ou serverless onde os pods escalam para cima e para baixo, essa diferença importa.

Índices: diferença de 1.700x no Neo4j, ~1x no FalkorDB

Sem índices, a consulta deep_feature_products do Neo4j levou 293ms. Com índices, 0.17ms. Isso é uma diferença de 1.712x. Memgraph mostrou sensibilidade semelhante (160-898x dependendo da consulta). Os resultados do FalkorDB ficaram praticamente os mesmos com ou sem índices porque as tabelas hash do Redis já funcionam como índices implícitos.

Memória: 415MB vs 2.668MB para o mesmo grafo

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

A JVM do Neo4j pré-aloca 4GB na inicialização, portanto sua memória no nível do processo (VmRSS) é sempre ~5.2GB independentemente do uso real de dados. A métrica de heap JMX é a significativa. O pico de 2.7GB é o número a ser usado para planejamento de capacidade.

Neo4j venceu a agregação mais pesada

FalkorDB teve a menor latência em 11 de 12 consultas. A exceção foi agg_feature_sentiment (agrupamento por sentimento com filtragem), em que o otimizador de consultas do Neo4j produziu um plano de execução melhor: 131ms vs 152ms do FalkorDB.

Carga de trabalho mista (80% leitura, 20% escrita)

8 threads, 60 segundos, zero erros em todos os três bancos de dados:

• FalkorDB: 50.223 operações (837 QPS)
• Neo4j: 44.256 operações (738 QPS)
• Memgraph: 28.040 operações (467 QPS)

As operações de escrita não degradaram visivelmente o desempenho de leitura em nenhum deles.

Arquiteturas neste benchmark

Cada banco de dados vem com sua própria interface de gerenciamento. Estas capturas de tela mostram o mesmo dataset (16.127 nós, 24.318 arestas) carregado nos três, executando a mesma consulta de travessia COMPARED_WITH.

FalkorDB

FalkorDB é um módulo de grafo construído sobre o armazenamento chave-valor em memória do Redis. As consultas são openCypher, mas por baixo são tabelas hash do Redis. É por isso que as pesquisas pontuais ficam em 0.044-0.048ms.
Os outros dois bancos de dados neste benchmark mediram 2-3x mais altos nas mesmas consultas. A desvantagem é que o núcleo de thread única do Redis significa que a vazão concorrente para de escalar depois de 8 threads

Neo4j

Neo4j roda na JVM. A compilação JIT significa que consultas repetidas ficam mais rápidas ao longo do tempo (aquecimento: 274ms -> 34ms). As pausas do GC afetam a latência de cauda, mas são capturadas pela remoção de outliers IQR. O otimizador de consultas lida bem com planos de agregação complexos, e é daí que vem a vitória do agg_feature_sentiment. O custo é a pré-alocação de heap de 4GB e a sobrecarga do GC.

Memgraph

Memgraph é escrito em C++. Sem sobrecarga de JVM. 415MB para o dataset completo, o menor dos três. Mais rápido em inserções individuais (1.427/s) graças à sobrecarga mínima por consulta. Mas fica para trás na vazão concorrente (pico de 684 QPS). Compatível com Bolt, então funciona com o driver do Neo4j.

Metodologia do benchmark de banco de dados de grafos

Ambiente

• RunPod 8 vCPU (AMD EPYC x86_64), 32GB RAM, Ubuntu 24.04 LTS
• Instalação nativa, sem Docker. Todos os três bancos de dados na mesma máquina, conexões localhost.
• Python 3.12.3. Sessões persistentes para testes de thread única, sessões por chamada a partir de um pool de conexões para testes multithread.

Dados

• 120.000 avaliações sintéticas geradas a partir das distribuições Zipf (marcas, características) e Poisson (entidades, relacionamentos), seed fixo=42.
• 6 tipos de nós: Review, Product, Reviewer, Brand, Feature, Category
• 8 tipos de arestas: ABOUT, WRITTEN_BY, IN_CATEGORY, MADE_BY, HAS_POSITIVE, HAS_NEGATIVE, MENTIONS, COMPARED_WITH

Consultas

12 modelos Cypher em 5 categorias: pesquisa pontual (3), travessia de 1 salto (2), travessia de 2 saltos (2), agregação (3), filtro (1), varredura completa (1). Cada consulta parametrizada executa com 10 valores de parâmetro diferentes, 100 vezes cada, totalizando 1.000 medições por consulta por banco de dados.

Os parâmetros são amostrados de todo o espaço de IDs usando seleção ponderada por Zipf, para que itens populares e raros sejam testados.

Três exemplos:

Pesquisa pontual: Busca um único nó por ID indexado

Travessia de 2 saltos: Percorre de uma marca através de seus produtos até as avaliações deles

Agregação: Varredura completa do grafo com junção de múltiplos saltos e computação

Medição

• Temporização: time.perf_counter_ns(), 500 consultas de aquecimento, 100 execuções por consulta no mínimo
• Estatísticas: 10.000 amostras de bootstrap, 95% IC, remoção de outliers IQR (fator 3.0x). Tanto os dados brutos quanto os filtrados são relatados.
• Memória: Neo4j via heap JMX usado (VmRSS é irrelevante porque a JVM pré-aloca), FalkorDB via Redis used_memory_rss, Memgraph via /proc/{pid}/status VmRSS.

Equidade

• Mesmo tamanho de pool de conexões, contagem de aquecimento, consultas Cypher, dados e máquina nos três bancos de dados.
• Teste concorrente: carga sustentada de 60 segundos em 1, 2, 4, 8, 16 e 32 threads com pool_size fixo=32. Mistura de consultas: 40% travessia de 1 salto, 30% travessia de 2 saltos, 20% agregação, 10% travessia de 3 saltos.
  

Bancos de dados testados

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Limitações

Máquina única, nó único por banco de dados. Nenhum benchmark distribuído ou de cluster. Clusterização do Neo4j Enterprise e replicação do Memgraph estão fora do escopo.

Dados sintéticos com distribuições derivadas de avaliações reais da Amazon. Podem não corresponder a padrões específicos de carga de trabalho em produção.

Não medido: persistência/recuperação em disco, busca de texto completo, algoritmos de grafo (PageRank, detecção de comunidades) e cargas de trabalho com predominância de escrita (>50% de escritas).

Drivers diferentes: Neo4j e Memgraph usaram o driver Python do Neo4j, FalkorDB usou o seu próprio. A diferença de sobrecarga foi <0.5ms em testes de thread única.

Cite esta pesquisa

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Benchmark de banco de dados de grafos: Neo4j vs FalkorDB vs Memgraph}},
  year   = {2026},
  month  = apr,
  howpublished    = {\url{https://aimultiple.com/graph-databases}},
  note   = {AIMultiple. Acessado em 15 Abril 2026}
}

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é Pesquisador de IA e Analista de Dados na AIMultiple. Ele projeta e executa benchmarks práticos para sistemas de IA e LLM.

Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

Nome

Endereço de email

Comentário

0/450

Postar comentário