← Voltar à lista

Neo4j na pratica: quando o grafo supera um BD comum

Neo4j e um banco de dados de grafos onde os dados vivem como nos e relacionamentos, nao como linhas em tabelas. Um BD relacional comum (PostgreSQL, MySQL) cobre muito bem transacoes, relatorios e CRUD. Mas quando o valor do produto esta em caminhos, cadeias e ligacoes multi-hop, o SQL com JOIN e CTE recursivos fica pesado e fragil. Abaixo - sinais praticos de quando o Neo4j vence um BD "comum", e quando o grafo ainda e prematuro.

  • Grafo - nos (entidades) + arestas (relacionamentos tipados) + propriedades
  • Forca do Neo4j - travessia de relacionamentos em profundidade variavel
  • Ponto fraco do SQL - JOINs profundos, "amigos de amigos", cadeias de fraude/acesso
  • Nao substitui - CRUD transacional, estoque, analitica classica
  • Regra - escolha Neo4j quando a pergunta soa como "atraves de quem / de que / em N hops"

Em que um grafo difere das tabelas

No PostgreSQL voce modela relacionamentos com foreign keys e tabelas de ligacao (user_roles, follows, order_items). Uma consulta de profundidade fixa ainda e legivel. Uma consulta do tipo "encontre todos os nos num raio de 3-5 hops com filtros por tipo de relacionamento" vira um CTE recursivo ou muitos JOINs - e o plano de execucao cresce com a profundidade.

No Neo4j o relacionamento e first-class. O modelo fica mais perto de como as pessoas descrevem o dominio:

  • (:Person)-[:WORKS_AT]->(:Company)
  • (:Account)-[:TRANSFERED_TO]->(:Account)
  • (:User)-[:HAS_ROLE]->(:Role)-[:ALLOWS]->(:Permission)

Uma consulta em Cypher descreve um padrao, nao uma "cola de tabelas". Isso ajuda quando a profundidade do caminho nao e conhecida de antemao ou muda com frequencia.

Quando o Neo4j supera um BD comum

Escolha um grafo se os requisitos incluem regularmente:

  1. Travessia de profundidade variavel - "amigos de amigos", cadeia de suprimentos, caminho ate o dono raiz.
  2. Pattern matching sobre relacionamentos - encontrar subgrafos do tipo "A ligado a B via C sob a condicao D".
  3. Recomendacoes e entidades semelhantes pelo grafo - nao so por texto, mas por vizinhos comuns e caminhos.
  4. Fraude e risco - aneis, dispositivos compartilhados, caminhos curtos entre contas "estranhas".
  5. Permissoes e dependencias - quem acessa o que via papeis, grupos e heranca.
  6. Knowledge graph - produtos, documentos, pessoas, sistemas e relacoes explicitas entre eles.

Sinais de que o SQL ja "doi":

  • CTEs recursivos ficam mais longos a cada release;
  • o time teme mudar o esquema de relacionamentos;
  • a latencia cresce exatamente em JOINs profundos, nao em SELECTs simples;
  • o negocio pede "mostre a cadeia", nao "me de a linha por id".

Exemplo pratico: caminho e vizinhos comuns

Suponha que voce precise de empresas ligadas a uma pessoa em no maximo dois passos, filtradas por tipo de relacionamento.

MATCH path = (p:Person {id: $personId})-[:WORKS_AT|KNOWS*1..2]-(c:Company)
WHERE c.country = $country
RETURN DISTINCT c.name AS company, length(path) AS hops
ORDER BY hops, company
LIMIT 50;

O mesmo sentido em SQL costuma exigir recursao, deduplicacao cuidadosa e limites de profundidade. No grafo a formulacao fica mais perto da pergunta de negocio.

Exemplo de "vizinhos comuns" para recomendacoes:

MATCH (u:User {id: $userId})-[:BOUGHT]->(:Product)<-[:BOUGHT]-(other:User)
WHERE u <> other
WITH other, count(*) AS shared
ORDER BY shared DESC
LIMIT 20
RETURN other.id, shared;

Quando um BD comum ainda e melhor

Neo4j nao e um substituto universal do PostgreSQL.

Mantenha um BD relacional (ou comece por ele) se:

  • o fluxo principal e CRUD, pedidos, pagamentos, estoque, billing;
  • os relacionamentos tem profundidade fixa (1-2 JOINs) e sao estaveis por anos;
  • voce precisa de agregados pesados, funcoes de janela e relatorios estilo BI;
  • o time e forte em SQL e consultas de grafo sao raras;
  • a logica de "rede" e pequena e um CTE resolve sem dor.

Erro tipico: mover o produto inteiro para o Neo4j "porque grafos estao na moda". Voce ganha operacao extra e um encaixe fraco para o nucleo transacional.

Hibrido: PostgreSQL + Neo4j

Na pratica uma separacao costuma funcionar:

Camada Onde guardar Para que
Pedidos, usuarios, pagamentos PostgreSQL / MySQL Transacoes, integridade, relatorios
Relacionamentos, caminhos, papeis, dependencias Neo4j Traversal e pattern match
Busca semantica de texto Store vetorial RAG / semantic search

Fonte da verdade para dinheiro e status - o BD relacional. Sincronize o grafo via eventos (outbox, CDC, fila) ou em lotes. Assim voce nao duplica billing no Neo4j nem monta um grafo de fraude so com JOINs.

Como validar a hipotese em 1-2 semanas

  1. Liste 15-20 perguntas reais de usuarios/analistas.
  2. Marque quantas sao sobre caminhos, hops e "atraves de quem".
  3. Se essa parcela passar de ~30-40%, monte um piloto Neo4j com um subgrafo reduzido.
  4. Compare com SQL: legibilidade, latencia p95, custo de mudar o esquema.
  5. Estime o custo de sincronizar dados com o BD principal.

Se o piloto nao ganhar em latencia/clareza - fique no PostgreSQL. O grafo deve resolver dor, nao decorar a arquitetura.

Conclusao

Neo4j supera um BD comum onde o produto pensa em relacionamentos: cadeias, papeis, dependencias, fraude, knowledge graph, recomendacoes por grafo. Um BD comum vence onde o nucleo e transacoes, JOINs fixos e relatorios. Muitas vezes o otimo e um hibrido: SQL para fatos e dinheiro, grafo para estrutura e caminhos.

Se precisar decidir se vale extrair relacionamentos para o Neo4j, ou desenhar um piloto para o seu dominio - fale comigo.

Perguntas frequentes

Em que o Neo4j e fundamentalmente melhor que o PostgreSQL para relacionamentos?

Velocidade e clareza da travessia em profundidade variavel. No grafo as arestas sao indexadas como relacionamentos, nao montadas a cada vez via JOINs de tabelas. Para 1-2 JOINs fixos o PostgreSQL costuma bastar; para "N hops com filtros por tipo de relacionamento" o Neo4j costuma ser mais simples e estavel.

CTEs recursivos no PostgreSQL podem substituir o Neo4j?

As vezes sim, no inicio. Se a profundidade e pequena, o grafo moderado e ha poucas consultas - CTEs funcionam. Quando crescem profundidade, ramificacao e o numero de consultas de padrao, CTEs ficam dificeis de manter e caros no plano de execucao.

E preciso mover o produto inteiro para o Neo4j?

Nao. Mova a camada onde relacionamentos sao valor de produto. Deixe pedidos, pagamentos, estoque e CRUD classico no BD relacional. Caso contrario, voce tera encaixe fraco e complexidade operacional extra.

Cypher e mais dificil que SQL?

E outro modelo mental, nao necessariamente mais dificil. Para caminhos e padroes o Cypher e mais curto e legivel. Para agregados, relatorios e funcoes de janela o SQL e mais familiar. O time precisa de um onboarding curto e 5-10 consultas de referencia do dominio.

Como comecar a adocao do Neo4j num projeto existente?

Com um piloto de um cenario: por exemplo grafo de acessos, aneis de fraude ou mapa de dependencias de servicos. Defina a fonte da verdade, o modo de sincronizacao e 10 perguntas de controle. So apos medir latencia e hit-rate decida expandir para outros dominios.

Contato