SeekDB

KI-Agenten, die ihr Arbeitsgedächtnis in einer Datenbank halten, stoßen auf ein Muster, mit dem die meisten Speicher schlecht umgehen: Sie schreiben permanent und lesen fast sofort wieder, und gleichzeitig müssen sie semantische Ähnlichkeit, Keyword-Treffer und strukturierte Filter in derselben Abfrage mischen. Klassische Vector-Stores und relationale Datenbanken zeigen Latenzspitzen, sobald Schreibvorgänge und Suchen konkurrieren, und zwingen Teams dazu, eine Vector-Engine, einen Volltextindex und eine SQL-Datenbank zusammenzustückeln. SeekDB, gebaut vom OceanBase-Team, zielt genau auf diese Last. Es verbindet ACID-konforme relationale Speicherung mit hybrider Vector-, Volltext- und Skalarsuche in einer einzigen SQL-Abfrage und ergänzt eine Copy-on-Write-Sandbox für Agenten, die etwas ausprobieren und wieder zurückrollen müssen.

Der Entwurf von SeekDB dreht sich darum, frisch geschriebene Daten sofort durchsuchbar zu halten, ohne Latenzspitzen. Eine asynchrone Indexierungs-Pipeline, die das Projekt Change Stream nennt, entkoppelt das Schreib-Commit vom Indexaufbau, und ein zweistufiger HNSW-Vector-Index, einer inkrementell, einer als Snapshot, macht neue Vektoren unmittelbar abfragbar. Markanter ist FORK/MERGE: Copy-on-Write-Sandboxes, die die Datenbank in Sekunden ohne Datenverdopplung abbilden, sodass ein Agent abzweigen, experimentieren und die Änderungen dann zurückführen oder verwerfen kann. Die Hybridsuche führt Vector-Ähnlichkeit, Volltexttreffer und Skalarfilter in einem Statement aus und erspart das Zusammenführen auf Clientseite. Da SeekDB das MySQL-Protokoll spricht, funktionieren vorhandene ORMs, Clients und GUIs unverändert, und es läuft eingebettet per pip, als eigenständiger Server oder als OceanBase-Cluster-Knoten.

Am klarsten passt es zu Multi-Agent- und Planungssystemen, die ein dauerhaftes, abfragbares Gedächtnis mit verzweigtem Zustand brauchen. Ein Agent, der eine Strategie spekulativ durchspielt, kann den Speicher forken, seine hypothetischen Änderungen schreiben, das Ergebnis bewerten und dann mergen oder verwerfen, ohne das geteilte Gedächtnis zu verschmutzen, was auf einer klassischen Datenbank umständlich ist. Darüber hinaus eignet sich SeekDB für RAG und unternehmensweite Frage-Antwort-Systeme, semantische Suche über gemischte Daten, KI-gestützte Codesuche und Edge- oder On-Device-Szenarien, in denen eine einzige eingebettete Engine einfacher ist als getrennte Vector- und SQL-Dienste. Die MySQL-Kompatibilität senkt die Einstiegshürde, und Integrationen mit LangChain, LlamaIndex und Dify sind dokumentiert, sodass es sich ohne eigenen Client in bestehende Agent- und Retrieval-Pipelines einfügt.

Die Vorbehalte sind real und gehören abgewogen. Die plakativen Performance-Zahlen, darunter die Behauptung von rund 10,7-fachem Milvus-Durchsatz und 3,2-fachem Elasticsearch, stammen aus den eigenen Benchmarks des Projekts ohne unabhängige Reproduktion und sind daher als Herstellerangaben zu lesen, nicht als gesicherte Ergebnisse. Das Repository zeigt eine hohe Zahl offener Issues im Verhältnis zu den Stars, was typischerweise auf frühe Kanten und eine noch bewegliche API hindeutet. Der Kern besteht zu etwa 97 Prozent aus C++, was Debugging und Beiträge für die Python- und JavaScript-Entwickler erschwert, die einen großen Teil der Agent-Bauer ausmachen, trotz der Python-Bindings. Das FORK/MERGE-Primitiv ist echt neuartig, doch Neuheit heißt auch weniger erprobte Muster, weniger Community-Wissen und ein Speicherformat, das sich zwischen Releases noch ändern kann.

Gegenüber Weaviate und Milvus tauscht SeekDB deren Reife und große operative Erfahrung gegen zwei Dinge, die jene Werkzeuge nicht sauber bieten: eine einzige SQL-Oberfläche über relationale, Vector- und Volltextdaten sowie das FORK/MERGE-Verzweigungsmodell. Wer ein Multi-Agent-System baut, das ein dauerhaftes Gedächtnis braucht, das es spekulativ verzweigen und zurückrollen kann, sollte SeekDB ernsthaft prototypisieren, und der eingebettete pip-Install macht den Test günstig. Für produktives RAG mit Bedarf an bewährter Stabilität, planbaren Upgrades und breitem Erfahrungsschatz bleiben die etablierten Engines heute die sicherere Wahl. Das ehrliche Fazit: vielversprechend und ungewöhnlich gut motiviert, aber noch früh. Setze es dort ein, wo sein verzweigtes Gedächtnismodell der eigentliche Zweck ist, und warte dort, wo du vor allem einen verlässlichen Vector-Index brauchst.