← Zurück zur Übersicht

Neo4j in der Praxis: wann ein Graph besser ist als eine gewoehnliche DB

Neo4j ist eine Graphdatenbank, in der Daten als Knoten und Beziehungen leben - nicht als Zeilen in Tabellen. Eine gewoehnliche relationale DB (PostgreSQL, MySQL) eignet sich hervorragend fuer Transaktionen, Reports und CRUD. Aber wenn der Produktwert in Pfaden, Ketten und mehrstufigen Beziehungen liegt, wird SQL mit JOINs und rekursiven CTEs schnell schwer und fragil. Unten - praktische Signale, wann Neo4j gegenueber einer "gewoehnlichen" DB gewinnt, und wann ein Graph noch zu frueh ist.

  • Graph - Knoten (Entitaeten) + Kanten (typisierte Beziehungen) + Eigenschaften
  • Staerke von Neo4j - Traversal von Beziehungen mit variabler Tiefe
  • Schwaeche von SQL - tiefe JOINs, "Freunde von Freunden", Fraud-/Zugriffs-Ketten
  • Kein Ersatz - transaktionales CRUD, Lager, klassische Analytik
  • Regel - Neo4j nehmen, wenn die Frage klingt wie "ueber wen / ueber was / in N Hops"

Worin sich Graph und Tabellen unterscheiden

In PostgreSQL modellieren Sie Beziehungen ueber Foreign Keys und Link-Tabellen (user_roles, follows, order_items). Eine Abfrage mit fester Tiefe ist noch lesbar. Eine Abfrage wie "finde alle Knoten im Radius von 3-5 Hops mit Filtern nach Beziehungstyp" wird zu einem rekursiven CTE oder vielen JOINs - und der Ausfuehrungsplan waechst mit der Tiefe.

In Neo4j ist eine Beziehung first-class. Das Modell liegt naeher an der Art, wie Menschen die Domaene beschreiben:

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

Eine Cypher-Abfrage beschreibt ein Muster, nicht ein "Zusammenkleben von Tabellen". Das hilft, wenn die Pfadtiefe vorher unbekannt ist oder sich oft aendert.

Wann Neo4j besser ist als eine gewoehnliche DB

Nehmen Sie einen Graphen, wenn im Lastenheft regelmaessig solche Aufgaben vorkommen:

  1. Variabler Beziehungs-Traversal - "Freunde von Freunden", Lieferkette, Pfad zum Root-Eigentuemer.
  2. Pattern Matching ueber Beziehungen - Teilgraphen finden wie "A ist mit B ueber C verbunden unter Bedingung D".
  3. Empfehlungen und aehnliche Entitaeten ueber den Graph - nicht nur per Text, sondern ueber gemeinsame Nachbarn und Pfade.
  4. Fraud und Risiko - Ringe, gemeinsame Geraete, kurze Pfade zwischen "fremden" Konten.
  5. Rechte und Abhaengigkeiten - wer worauf Zugriff hat ueber Rollen, Gruppen und Vererbung.
  6. Knowledge Graph - Produkte, Dokumente, Personen, Systeme und explizite Beziehungen dazwischen.

Signale, dass SQL bereits "weh tut":

  • rekursive CTEs werden mit jedem Release laenger;
  • das Team scheut Aenderungen am Beziehungsschema;
  • Latency steigt genau bei tiefen JOINs, nicht bei einfachen SELECTs;
  • das Business fragt "zeig die Kette", nicht "gib die Zeile per id".

Praxisbeispiel: Pfad und gemeinsame Nachbarn

Angenommen, Sie brauchen Unternehmen, die mit einer Person in hoechstens zwei Schritten verbunden sind, gefiltert nach Beziehungstyp.

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;

Derselbe Sinn in SQL braucht meist Rekursion, sorgfaeltige Deduplizierung und Tiefenlimits. Im Graph ist die Formulierung naeher an der Business-Frage.

Beispiel "gemeinsame Nachbarn" fuer Empfehlungen:

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;

Wann eine gewoehnliche DB weiterhin besser ist

Neo4j ist kein universeller Ersatz fuer PostgreSQL.

Bleiben Sie bei einer relationalen DB (oder starten Sie damit), wenn:

  • der Hauptfluss CRUD, Bestellungen, Zahlungen, Lager, Billing ist;
  • Beziehungen feste Tiefe haben (1-2 JOINs) und jahrelang stabil bleiben;
  • schwere Aggregate, Fensterfunktionen und BI-Reports noetig sind;
  • das Team stark in SQL ist und Graph-Abfragen selten vorkommen;
  • die "Netzwerk"-Logik klein ist und ein CTE ohne Schmerz ausreicht.

Typischer Fehler: das ganze Produkt nach Neo4j ziehen, "weil Graphen trendy sind". Sie bekommen extra Betrieb und einen schwachen Fit fuer den Transaktionskern.

Hybrid: PostgreSQL + Neo4j

In der Praxis funktioniert oft eine Trennung:

Schicht Wo speichern Warum
Bestellungen, Nutzer, Zahlungen PostgreSQL / MySQL Transaktionen, Integritaet, Reports
Beziehungen, Pfade, Rollen, Abhaengigkeiten Neo4j Traversal und Pattern Match
Semantische Textsuche Vektorspeicher RAG / Semantic Search

Source of Truth fuer Geld und Status - die relationale DB. Den Graph synchronisieren Sie per Events (Outbox, CDC, Queue) oder Batches. So duplizieren Sie Billing nicht in Neo4j und bauen keinen Fraud-Graph nur aus JOINs.

Hypothese in 1-2 Wochen pruefen

  1. Schreiben Sie 15-20 echte Fragen von Nutzern/Analysten auf.
  2. Markieren Sie, wie viele davon Pfade, Hops und "ueber wen" betreffen.
  3. Liegt der Anteil ueber ~30-40%, bauen Sie einen Neo4j-Pilot mit einem reduzierten Teilgraphen.
  4. Vergleichen Sie mit SQL: Lesbarkeit, p95-Latency, Kosten von Schema-Aenderungen.
  5. Schaetzen Sie die Kosten der Datensync mit der Primaer-DB.

Gewinnt der Pilot nicht bei Latency/Klarheit - bleiben Sie bei PostgreSQL. Ein Graph soll Schmerz loesen, nicht die Architektur verzieren.

Fazit

Neo4j ist besser als eine gewoehnliche DB dort, wo das Produkt in Beziehungen denkt: Ketten, Rollen, Abhaengigkeiten, Fraud, Knowledge Graph, graphbasierte Empfehlungen. Eine gewoehnliche DB ist besser dort, wo der Kern Transaktionen, feste JOINs und Reports sind. Oft optimal ist ein Hybrid: SQL fuer Fakten und Geld, Graph fuer Struktur und Pfade.

Wenn Sie klaeren wollen, ob Beziehungen nach Neo4j gehoeren, oder einen Pilot fuer Ihre Domaene brauchen - kontaktieren Sie mich.

Haeufig gestellte Fragen

Worin ist Neo4j fuer Beziehungen grundsaetzlich besser als PostgreSQL?

Geschwindigkeit und Klarheit beim Traversal mit variabler Tiefe. Im Graph sind Kanten als Beziehungen indexiert, nicht jedes Mal ueber Tabellen-JOINs zusammengebaut. Fuer 1-2 feste JOINs reicht PostgreSQL oft; fuer "N Hops mit Filtern nach Beziehungstyp" ist Neo4j meist einfacher und stabiler.

Koennen rekursive CTEs in PostgreSQL Neo4j ersetzen?

Manchmal ja, am Anfang. Bei kleiner Tiefe, maessigem Graph und wenigen Abfragen funktionieren CTEs. Wachsen Tiefe, Verzweigung und Zahl der Pattern-Abfragen, werden CTEs schwer wartbar und teuer im Ausfuehrungsplan.

Muss das ganze Produkt nach Neo4j wandern?

Nein. Verschieben Sie die Schicht, in der Beziehungen Produktwert sind. Bestellungen, Zahlungen, Lager und klassisches CRUD bleiben in der relationalen DB. Sonst bekommen Sie einen schwachen Fit und unnoetige Betriebs-Komplexitaet.

Ist Cypher schwieriger als SQL?

Ein anderes mentales Modell, nicht zwingend schwieriger. Fuer Pfade und Muster ist Cypher kuerzer und lesbarer. Fuer Aggregate, Reporting und Fensterfunktionen ist SQL vertrauter. Das Team braucht ein kurzes Onboarding und 5-10 Referenzabfragen zur Domaene.

Wie mit der Einfuehrung von Neo4j in ein bestehendes Projekt starten?

Mit einem Pilot zu einem Szenario: z. B. Zugriffsgraph, Fraud-Ringe oder Service-Abhaengigkeitskarte. Definieren Sie Source of Truth, Sync-Weg und 10 Kontrollfragen. Erst nach Messung von Latency und Hit-Rate entscheiden Sie ueber die Ausweitung auf andere Domaenen.

Kontakt