← Volver al listado

Neo4j en la practica: cuando el grafo supera a una BD normal

Neo4j es una base de datos de grafos donde los datos viven como nodos y relaciones, no como filas en tablas. Una BD relacional normal (PostgreSQL, MySQL) cubre muy bien transacciones, informes y CRUD. Pero cuando el valor del producto esta en rutas, cadenas y enlaces de varios saltos, el SQL con JOIN y CTE recursivos se vuelve pesado y fragil. Abajo - senales practicas de cuando Neo4j gana a una BD "normal", y cuando el grafo aun es prematuro.

  • Grafo - nodos (entidades) + aristas (relaciones tipadas) + propiedades
  • Fuerza de Neo4j - recorrido de relaciones a profundidad variable
  • Punto debil del SQL - JOIN profundos, "amigos de amigos", cadenas de fraude/acceso
  • No sustituye - CRUD transaccional, inventario, analitica clasica
  • Regla - elija Neo4j cuando la pregunta suena a "a traves de quien / de que / en N hops"

En que se diferencia un grafo de las tablas

En PostgreSQL modela relaciones con foreign keys y tablas de enlace (user_roles, follows, order_items). Una consulta de profundidad fija sigue siendo legible. Una consulta del tipo "encuentra todos los nodos en un radio de 3-5 hops con filtros por tipo de relacion" se convierte en un CTE recursivo o muchos JOIN - y el plan de ejecucion crece con la profundidad.

En Neo4j la relacion es first-class. El modelo se acerca a como las personas describen el dominio:

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

Una consulta en Cypher describe un patron, no un "pegado de tablas". Eso ayuda cuando la profundidad del camino no se conoce de antemano o cambia a menudo.

Cuando Neo4j supera a una BD normal

Elija un grafo si en los requisitos aparecen con regularidad tareas como:

  1. Recorrido de profundidad variable - "amigos de amigos", cadena de suministro, ruta hasta el propietario raiz.
  2. Pattern matching sobre relaciones - encontrar subgrafos del tipo "A vinculado a B via C bajo la condicion D".
  3. Recomendaciones y entidades similares por el grafo - no solo por texto, sino por vecinos comunes y caminos.
  4. Fraude y riesgo - anillos, dispositivos compartidos, caminos cortos entre cuentas "ajenas".
  5. Permisos y dependencias - quien accede a que a traves de roles, grupos y herencia.
  6. Knowledge graph - productos, documentos, personas, sistemas y relaciones explicitas entre ellos.

Senales de que el SQL ya "duele":

  • los CTE recursivos se alargan en cada release;
  • el equipo teme cambiar el esquema de relaciones;
  • la latencia crece justo en JOIN profundos, no en SELECT simples;
  • el negocio pregunta "muestra la cadena", no "dame la fila por id".

Ejemplo practico: camino y vecinos comunes

Suponga que necesita empresas vinculadas a una persona en como maximo dos pasos, filtradas por tipo de relacion.

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;

El mismo sentido en SQL suele exigir recursion, deduplicacion cuidadosa y limites de profundidad. En el grafo la formulacion esta mas cerca de la pregunta de negocio.

Ejemplo de "vecinos comunes" para recomendaciones:

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;

Cuando una BD normal sigue siendo mejor

Neo4j no es un reemplazo universal de PostgreSQL.

Mantenga una BD relacional (o empiece con ella) si:

  • el flujo principal es CRUD, pedidos, pagos, inventario, billing;
  • las relaciones tienen profundidad fija (1-2 JOIN) y son estables durante anos;
  • necesita agregados pesados, funciones de ventana e informes estilo BI;
  • el equipo es fuerte en SQL y las consultas de grafo son pocas;
  • la logica de "red" es pequena y un CTE la cubre sin dolor.

Error tipico: mover todo el producto a Neo4j "porque los grafos estan de moda". Obtendra mas operacion y un mal encaje para el nucleo transaccional.

Hibrido: PostgreSQL + Neo4j

En la practica suele funcionar una separacion:

Capa Donde guardar Para que
Pedidos, usuarios, pagos PostgreSQL / MySQL Transacciones, integridad, informes
Relaciones, rutas, roles, dependencias Neo4j Traversal y pattern match
Busqueda semantica de texto Almacen vectorial RAG / semantic search

La fuente de verdad del dinero y los estados - la BD relacional. Sincronice el grafo con eventos (outbox, CDC, cola) o por lotes. Asi no duplica el billing en Neo4j ni construye un grafo de fraude solo con JOIN.

Como validar la hipotesis en 1-2 semanas

  1. Anote 15-20 preguntas reales de usuarios/analistas.
  2. Marque cuantas tratan de rutas, hops y "a traves de quien".
  3. Si esa parte supera ~30-40%, monte un piloto en Neo4j con un subgrafo reducido.
  4. Compare con SQL: legibilidad, latencia p95, coste de cambiar el esquema.
  5. Estime el coste de sincronizar datos con la BD principal.

Si el piloto no gana en latencia/claridad - quedese en PostgreSQL. El grafo debe resolver dolor, no decorar la arquitectura.

Conclusion

Neo4j supera a una BD normal donde el producto piensa en relaciones: cadenas, roles, dependencias, fraude, knowledge graph, recomendaciones por grafo. Una BD normal gana donde el nucleo son transacciones, JOIN fijos e informes. A menudo lo optimo es un hibrido: SQL para hechos y dinero, grafo para estructura y rutas.

Si necesita decidir si conviene sacar las relaciones a Neo4j, o disenar un piloto para su dominio - contacteme.

Preguntas frecuentes

En que Neo4j es fundamentalmente mejor que PostgreSQL para relaciones?

En velocidad y claridad del recorrido a profundidad variable. En el grafo las aristas se indexan como relaciones, no se ensamblan cada vez con JOIN de tablas. Para 1-2 JOIN fijos PostgreSQL suele bastar; para "N hops con filtros por tipo de relacion" Neo4j suele ser mas simple y estable.

Pueden los CTE recursivos de PostgreSQL reemplazar Neo4j?

A veces si, al inicio. Si la profundidad es pequena, el grafo moderado y hay pocas consultas - los CTE funcionan. Cuando crecen la profundidad, la ramificacion y el numero de consultas de patron, los CTE se vuelven dificiles de mantener y caros en el plan de ejecucion.

Hay que mover todo el producto a Neo4j?

No. Mueva la capa donde las relaciones son valor de producto. Deje pedidos, pagos, inventario y CRUD clasico en la BD relacional. Si no, obtendra un mal encaje y mas complejidad operativa.

Es Cypher mas dificil que SQL?

Es otro modelo mental, no necesariamente mas dificil. Para caminos y patrones Cypher es mas corto y legible. Para agregados, informes y funciones de ventana SQL es mas familiar. El equipo necesita un onboarding corto y 5-10 consultas de referencia del dominio.

Como empezar a adoptar Neo4j en un proyecto existente?

Con un piloto de un escenario: por ejemplo grafo de accesos, anillos de fraude o mapa de dependencias de servicios. Defina la fuente de verdad, el modo de sincronizacion y 10 preguntas de control. Solo tras medir latencia y hit-rate decida ampliar a otros dominios.

Contacto