Für die OSPO-Arbeit brauchten wir einen Ort, an dem Wissen über unsere Open-Source-Nutzung zusammenläuft: Pakete, Lizenzen, SBOMs – und wer sich womit auskennt. Das klang nach einem Wissensgraphen und damit nach einer Graphdatenbank.
Der Vergleich
Ich habe mir ArcadeDB und Neo4j genauer angesehen und dabei auch die Frage gestellt, ob RDF und SPARQL oder ein Property Graph besser passen. Beide Datenbanken können deutlich mehr, als wir brauchen. Genau das war das Problem: Jede Fähigkeit, die wir nicht nutzen, will trotzdem betrieben, aktualisiert und verstanden werden.
Die Größe des Problems sollte die Größe der Lösung bestimmen – nicht umgekehrt.
Die kleinere Antwort
Für die Datenmenge, um die es tatsächlich geht, reicht SQLite: FTS5 für die Volltextsuche, sqlite-vec für semantische Ähnlichkeit und ein paar gewöhnliche Tabellen für die Beziehungen. Eine Datei, kein Dienst, kein Betrieb.
CREATE VIRTUAL TABLE docs_fts USING fts5(title, body);
CREATE VIRTUAL TABLE docs_vec USING vec0(embedding float[768]);
-- Beziehungen bleiben ganz normale Tabellen
CREATE TABLE edges (src TEXT, rel TEXT, dst TEXT);Was ich mitnehme
Es fühlt sich weniger beeindruckend an, eine Datei zu empfehlen als eine Graphdatenbank. Aber gute Developer Experience heißt auch, nichts betreiben zu müssen, was man nicht braucht. Wenn wir herauswachsen, wechseln wir – und wissen dann sehr viel genauer, wohin.
Danke an alle fürs Gegenlesen und für die Frage, die alles ins Rollen gebracht hat.