Handbücher · Wissensgraphen
Graph-Stores
Lernziele
- Du ordnest die vier Arten von Graph-Stores auf einer Leiter vom Text zum Server.
- Du erklärst am Beispiel Kuzu, welches Risiko eine Datenbank für deinen Graphen bedeutet.
- Du wählst für eine gegebene Lage den passenden Store und begründest, warum der Store nach der Pipeline kommt.
Wo der Graph liegt, ist weniger wichtig, als viele denken, und wichtiger, als Anbieter zugeben. Für persönliche Bestände und Agenten in kleinem Maßstab lohnt es sich, von unten anzufangen: beim reinen Text. Die Datenbank kommt erst, wenn etwas sie verlangt.
Wikilinks als Graph
Ein Ordner mit Markdown-Dateien, in dem [[Seite]]-Links die Kanten sind, ist ein Wissensgraph. Entitäten sind Seiten, Beziehungen sind Links, typisiert, wenn du typisierte Links nutzt. Der Store ist das Dateisystem. Auf diesem Muster baut das ganze Praxisprojekt Second Brain auf.
Ein Agent fragt diesen Graphen mit grep und folgt den Links. Du fragst ihn in Obsidian. Es gibt keinen Server, keinen Treiber und keine Migration, und die Person, der der Graph gehört, kann ihn lesen. Bei einigen tausend Knoten ist das nach unserer Einschätzung die richtige Wahl.
NetworkX in Dateien
Brauchst du Algorithmen wie PageRank, Community-Erkennung oder Zentralität, lädst du den Graphen in NetworkX und speicherst ihn als GraphML oder JSON neben deinen Notizen. Das ist Python im Arbeitsspeicher, ohne Infrastruktur, und reicht bis in die Zehntausende von Knoten. Wie du den Graphen aus einem Vault dorthin exportierst, zeigt die Lektion Graph exportieren.
Mehrere GraphRAG-Implementierungen nutzen genau das als Standard-Backend. LightRAG speichert seinen Graphen ohne weitere Einstellung mit NetworkX. Für den Betrieb empfiehlt es ein anderes Backend wie PostgreSQL, für Tests und kleine Bestände reicht NetworkX.
Eingebettete Datenbanken und die Lehre aus Kuzu
Kuzu war die naheliegende eingebettete Wahl: DuckDB für Graphen, mit Cypher als Abfragesprache und einer einzigen Datei. Am 10. Oktober 2025 wurde das Repository archiviert, die letzte Version ist 0.11.3. Später bestätigte eine Meldung bei der EU-Kommission, dass Apple das Team von Kùzu Inc. übernommen hatte.
Kuzu läuft weiterhin, und es gibt Forks aus der Community. Aktiv entwickelt wird zum Beispiel LadybugDB. Die Episode ist trotzdem das Argument für die unteren Stufen der Leiter. Die MIT-Lizenz hat den Code gerettet. Reine Dateien hätten keine Rettung gebraucht. Wie sich die eingebetteten Graphdatenbanken nach Kuzu sortieren, ist noch offen; einen Überblick gibt ein Beitrag von gdotv vom Mai 2026.
Server – Neo4j und FalkorDB
Neo4j ist der etablierte Anbieter: Cypher, das größte Ökosystem, erstklassige Anbindung in jedem Framework und eine kostenlose Stufe, die für den persönlichen Gebrauch reicht. Der Preis ist der Betrieb. Neo4j ist ein Server, und den betreibst du jetzt.
FalkorDB ist die leichtere Alternative: eine Graphdatenbank als Redis-Modul, ausgerichtet auf GraphRAG, mit einem eigenen, aktiv entwickelten SDK. Sie ist sinnvoll, wenn sich mehrere Agenten einen Graphen teilen und die Latenz der Abfragen zählt. Beachte die Lizenz: Der Kern steht unter der SSPLv1, die die Open Source Initiative nicht als Open-Source-Lizenz anerkennt.
Was wozu passt
Welcher Store?
Ordne jede Lage dem passenden Store zu.
Noch offen (4)
- Eine Person, gepflegter Bestand mit 2.000 Notizen
- Derselbe Vault, dazu einmal im Quartal Communities und Brückenseiten berechnen
- Ein einzelner Agent mit Langzeitgedächtnis über Graphiti
- Zwölf Agenten schreiben gleichzeitig in einen gemeinsamen Graphen
Wikilinks (0)
NetworkX über exportierte Links (0)
Standard der Gedächtnis-Bibliothek (0)
Echter Server (0)
Für einzelne Agenten bestimmt meist die Gedächtnis-Bibliothek den Store: Graphiti will Neo4j, FalkorDB oder Amazon Neptune, andere bringen NetworkX mit. Die Lektion Werkzeuge stellt sie vor.
Wähle den Store erst, wenn die Extraktions-Pipeline funktioniert. Ein Graph in Dateien zieht an einem Nachmittag nach Neo4j um. Beim umgekehrten Weg merken Projekte, dass ihr Graph den Server nie wert war. Die Schwellenlogik dazu steht in Warum Wissensgraphen.
Merksätze
- Ein Ordner mit Wikilinks ist ein Graph, und bei einigen tausend Knoten der richtige Store.
- Für Algorithmen lädst du den Graphen in NetworkX und speicherst ihn als GraphML oder JSON daneben.
- Kuzu wurde 2025 archiviert. Dateien in offenen Formaten überstehen das Ende eines Stores ohne Rettung.
- Neo4j und FalkorDB sind Server: nötig bei geteilten, nebenläufigen Schreibzugriffen, und dann zu betreiben.
- Der Store kommt nach der funktionierenden Pipeline.
Prüf dich selbst
Denkfrage
Warum reicht ein Ordner mit Wikilinks bei einigen tausend Knoten als Store?
Er braucht keinen Server, keinen Treiber und keine Migration. Agent und Mensch lesen ihn direkt, mit grep oder in Obsidian. Algorithmen holst du dir bei Bedarf über einen Export nach NetworkX, ohne den Store zu wechseln.
Denkfrage
Was zeigt die Archivierung von Kuzu über die Wahl eines Stores?
Ein Store kann wegfallen, auch wenn er technisch gut ist. Die offene Lizenz hat den Code gerettet. Wer den Graphen in offenen Dateiformaten hält, ist vom Schicksal eines einzelnen Produkts unabhängig.
Prüf dich selbst
Quellen
- NetworkX
Graphen in Python, Ein- und Ausgabe als GraphML und JSON.
- kuzudb/kuzu
Archiviert am 10. Okt. 2025, letzte Version 0.11.3, MIT-Lizenz.
- Kuzu’s Legacy and the New Wave of Embedded Graph Databases
Archivierung, Übernahme des Teams durch Apple, Forks.
- LadybugDB
Aktiver Fork von Kuzu. Stand: Nov. 2026.
- Neo4j
Graphdatenbank mit Cypher, kostenlose Stufe. Stand: Nov. 2026.
- FalkorDB
Graphdatenbank als Redis-Modul, Kern unter SSPLv1.
- LightRAG
Standard-Graphspeicher NetworkX, für den Betrieb PostgreSQL empfohlen.