Tot ist nicht das Gegenteil von richtig

Ich habe Wochen gesucht. Nicht nach irgendeiner Datenbank, nach der Datenbank für das HIRN. Das HIRN ist der Teil meines Systems, der Wissen nicht ablegt, sondern verknüpft: Dokumente, Entitäten, Kanten zwischen Entitäten, Vektoren für semantische Nähe, und über allem die Frage, die mich am meisten umtreibt: nicht nur was gilt, sondern was wann galt. Eine Abfrage über mehrere Dimensionen gleichzeitig: zeig mir alle Knoten, die mit diesem Thema verwandt sind, semantisch ähnlich zu jenem Text, vor sechs Monaten anders verbunden waren als heute. Das ist keine SQL-Frage. Das ist nicht mal eine Graph-Frage. Das ist alles auf einmal.

Und dann fand ich Cozo. // Embedded. Datalog für rekursive Graph-Abfragen. Relationales Modell. Vektor-Suche mit HNSW. Time-Travel eingebaut. Eine einzige Rust-Bibliothek, kein Server, kein Cluster, kein Betriebsaufwand. Der Tagline des Projekts ist „the hippocampus for AI". Ich habe laut gelacht, als ich das las, weil es exakt das ist, was ich bauen will. Der Hippocampus ist die Struktur im Gehirn, die Erinnerungen verknüpft und konsolidiert. Jemand hatte mein HIRN schon benannt, bevor ich es gebaut hatte.

Ich habe an dem Abend nicht aufgehört. Erste Queries, das Datalog-Modell durchgespielt, die Time-Travel-Semantik gegen meine Reconsolidation-Idee gehalten. Es passte an jeder einzelnen Stelle. Ich war verliebt, und Verliebtheit ist ein schlechter Architekt.

Am nächsten Morgen kam der Kater. Letztes getaggtes Release: v0.7.6, Dezember 2023. Die Repos der Organisation: letzte ernsthafte Aktivität 2024, danach Stille. Issues von Ende 2024, von Anfang 2025, offen, unbeantwortet. In einer Discussion fragt jemand im Oktober 2025, ob Cozo eine Alternative zum gerade archivierten KuzuDB sei, und bekommt die nüchterne Antwort: könnte passen, aber „has not been an active project for a long time". Das perfekte Werkzeug hatte seit zwei Jahren keinen Puls.

// Man verliebt sich nicht in das Werkzeug. Man verliebt sich in das Problem, das es löst. Und dann verwechselt man beides.

Es gibt einen Community Soft-Fork. Im September 2024 hat jemand unter cozo-community einen Fork aufgesetzt, ausdrücklich kein harter Fork, weil der ursprüngliche Entwickler „weiterhin unterstützt, wenn auch mit begrenzter Zeit". Eine Discord-Gruppe, ein bisschen CI/CD. Hoffnung. Aber auch dieser Fork atmet flach. Es ist die Sorte Projekt, die nicht stirbt und nicht lebt, sondern in einem Wartezimmer sitzt.

Und dann, mitten in der Stille, dieser eine Pull Request. PR #308, eröffnet im April 2026, von jemandem mit dem Handle lawless-m. Ein neuer Storage-Backend für Cozo, geschrieben in purem Rust auf Basis von redb 4.0: single-file, ACID, null C-Abhängigkeiten. Die Beschreibung ist trocken und stolz zugleich, „fits the same niche as sled but with a more active upstream", und darunter Benchmarks: 32 bis 49 Prozent schnellere Reads als SQLite, 2,35-fach schnellere Time-Travel-Aggregationen. Jemand hat sich hingesetzt und das gebaut, was das Projekt brauchen würde, um nicht an einer alternden C-Bibliothek zu hängen. Für ein Projekt, das offiziell tot ist. Der Status des PR, als ich ihn fand: offen. Kein Maintainer-Kommentar. Der letzte Mohikaner schickt Signalfeuer in einen leeren Wald.

Ich saß davor und dachte: Reicht das? Ein offener PR, ein schlafender Fork, ein Entwickler mit begrenzter Zeit. Das ist die ehrliche Frage, und sie hat keine bequeme Antwort.

Also habe ich die Alternativen sauber durchgespielt, eine nach der anderen, ohne sie schlechtzureden. Das bin ich dem Vergleich schuldig.

KuzuDB: eingebettet, schnell, Cypher statt Datalog. Wäre ein Kandidat gewesen, ist aber im Oktober 2025 archiviert worden; das Team wurde offenbar von Apple übernommen. Eine Community-Fork namens LadybugDB existiert, ohne Rückhalt. // Aus dem Regen in die Traufe: ein totes Projekt gegen ein anderes tauschen, das obendrein die falsche Sprache spricht.

DuckPGQ: eine Graph-Erweiterung für DuckDB, technisch beeindruckend, starke Benchmarks. Aber DuckDB ist eine analytische, spaltenorientierte Engine. Sie ist für große Aggregationen gebaut, nicht für das transaktionale Verknüpfen einzelner Wissensknoten in Echtzeit. SQL/PGQ statt Datalog. Das eine Modell, das ich am dringendsten brauche, rekursive Regeln über getypte Kanten, fehlt.

SurrealDB: die meistgenannte Empfehlung, multi-model, läuft sogar im Browser. Sympathisch. Aber die Lizenz ist BSL, nicht OSI-konform, und die eigene Query-Sprache SurrealQL ist mächtig, aber eben nicht Datalog. Ich würde mein Denkmodell der Datenbank unterordnen statt umgekehrt.

XTDB: bitemporal, genau die Time-Travel-Tiefe, die ich suche, mit Datalog-Wurzeln. Aber v2 ist server-basiert und auf SQL umgeschwenkt. Eingebettet ist es nicht mehr. Ein Server pro Wissensknoten skaliert in einem verteilten Netz nicht.

Memgraph: in-memory, schnell, Cypher, Neo4j-kompatibel. Server, BSL-Lizenz, kommerziell rund 25.000 im Jahr. Datomic: der Datalog-Klassiker, aber proprietär, JVM, server. Beide bauen für Unternehmen, nicht für ein eingebettetes HIRN auf jedem Knoten. (Eine brauchbare Übersicht der lebenden Datalog-Datenbanken pflegt clojurelog.github.io, falls jemand denselben Weg geht.)

Am Ende der Tabelle stand dasselbe wie bei Sunk Cost, nur umgekehrt: Diesmal war nicht mein Code der überlegene, sondern fremder, toter Code. Jede lebendige Alternative ist nett. Keine ist überzeugend. Sie decken Teilmengen ab, eingebettet oder Datalog oder Time-Travel oder Vektoren, aber keine die Schnittmenge, und die Schnittmenge ist das ganze Spiel. Cozo ist das einzige Werkzeug, das alles in einer Bibliothek ohne Server vereint. Es hat nur den einen Makel, dass niemand mehr drauf aufpasst.

// „Tot" und „ungeeignet" sind zwei Achsen, nicht eine. Wir verwechseln sie ständig, weil ein Puls leichter zu prüfen ist als eine Passung.

Iststand, ganz unspektakulär: Cozo ist ausgecheckt, die ersten Tests sind durchgelaufen. Der erste Eindruck ist gut, nicht euphorisch-verliebt wie am ersten Abend, sondern die nüchterne Variante davon, die länger hält. Ich habe den redb-Backend aus PR #308 lokal gegen meine Datenstruktur gehalten. Es trägt.

Und hier ist die Vision, die ich nicht mehr loswerde. In meiner ersten Skizze war Cozo ein Verarbeitungsknoten, eine Komponente, die auf dem verteilten HIRN-Netz läuft, eine von vielen, austauschbar. Beim Durchspielen kippte das. Cozo wird nicht ein Knoten auf dem Netz sein. Cozo wird das verteilte HIRN. Jeder Knoten eine eingebettete Cozo-Instanz, jede mit Datalog-Verstand und Time-Travel-Gedächtnis, untereinander synchronisiert. Kein Hippocampus im System, das System ist der Hippocampus. Das ist nicht mehr Werkzeugwahl. Das ist Architektur.

Aber bis dahin sind noch ein paar Meter zu gehen. Synchronisation zwischen den Knoten. Den redb-Backend produktionsreif. Mir selbst beweisen, dass ich bereit bin, das zu warten, was ein anderer fallen ließ, denn das ist der Preis. Wer ein totes Werkzeug aufhebt, wird sein Maintainer, ob er will oder nicht. Der Bus-Faktor wird nicht kleiner, wenn man einsteigt. Man wird nur selbst der eine im Bus.

Zum Schluss etwas, das nicht in eine Architektur-Tabelle passt. Cozo wurde von Ziyang Hu gebaut, einem promovierten theoretischen Physiker aus Cambridge, der sich der Verbindung von Datenbanken und KI verschrieben hat. Es gibt keinen großen Abschiedspost, kein „ich höre auf". Nur diesen einen leisen Satz, übersetzt durch einen anderen in Discussion #278: unterstützt weiterhin, aber mit begrenzter Zeit. Kein Knall. Ein Verklingen. Und ehrlich gesagt finde ich das würdevoller als jedes dramatische Manifest.

Wer auch immer du gerade bist, Ziyang. Du hast etwas gebaut, das ein Fremder zwei Jahre nach dem letzten Release noch für so gut hält, dass er lieber dein totes Projekt weiterträgt als ein lebendiges nimmt. Das ist die seltenste Form von Lob, die Software bekommen kann. Mach dir keine Sorgen um den Code. Geh spazieren, schlaf aus, denk an Physik. Wir passen drauf auf.

// Das Schönste, was man einem Werkzeug nachsagen kann, ist nicht, dass es gepflegt wird. Sondern dass jemand es pflegen will, obwohl es niemand mehr muss.