EdgeQuake: PostgreSQL-GraphRAG als MCP-Gedächtnis für Agenten

Zurück

Kevin Riedl

13 Min. Lesezeit · 12. Okt. 2026
Zuletzt geprüft 12. Oktober 2026

Weiter

EdgeQuake ist ein in Rust entwickelter GraphRAG-Server, der Dokumentensuche und Wissensgraph in PostgreSQL verbindet. Über MCP kann ein Agent auch in späteren Unterhaltungen auf die dort gespeicherten Quellenbelege zugreifen. Besonders interessant ist das für Fragen, deren Antwort über mehrere Dokumente verteilt ist: Welcher Lieferantenvertrag gilt etwa für ein Bauteil eines bestimmten Produkts?

Die am 11. Oktober 2026 veröffentlichte Version v0.34.0 bietet einen konkreten Anlass, diese Architektur zu prüfen. Für ein Team, das PostgreSQL bereits betreibt, kann ein gemeinsamer Speicher für Graph-, Vektor- und Dokumentendaten den Betrieb übersichtlicher machen.

Geprüft am 12. Oktober 2026. Diese Analyse stützt sich auf die Dokumentation und den Quellcode des Release-Tags. Die folgenden Beispiele sind vorgeschlagene Prüfschritte. Wavect hat den beschriebenen EdgeQuake-Stack nicht selbst betrieben und die Benchmarks nicht unabhängig reproduziert.

Was ändert sich mit EdgeQuake v0.34.0?

v0.34.0 ergänzt einen visuellen Rundgang und behält das Datenbankschema 169 bei. Laut den versionsbezogenen Upgrade-Hinweisen bleibt das Verhalten von Abfragen und Speicherung unverändert. Die Veröffentlichung übernimmt bestehende Genauigkeitsmessungen aus dem August. Verschlüsselte Anbieterverbindungen, Workspace-Isolation und MCP gehören zum bereits entwickelten Funktionsumfang; sie wurden nicht alle mit dieser Version eingeführt.

Diese Einordnung hilft bei der Upgrade-Planung. Beim Wechsel von v0.33.0 mit Schema 169 sollte der Migrationsbefehl keine ausstehenden Änderungen finden. Eine ältere Installation braucht den dafür dokumentierten Upgrade-Pfad. Die Veröffentlichung einer neuen Version belegt allein noch nicht, dass deine Datenbank dafür vorbereitet ist.

GraphRAG hilft bei Fragen nach Zusammenhängen

Das EdgeQuake-Repository beschreibt eine Rust-Implementierung des LightRAG-Ansatzes: Dokumente einlesen, Entitäten und Beziehungen extrahieren und passenden Kontext über Vektor- und Graphabfragen finden. PostgreSQL speichert die Daten. pgvector übernimmt die Vektorsuche, Apache AGE die Graphfunktionen.

Für eine erste Prüfung eignet sich dieser ausdrücklich fiktive Dokumentensatz:

Frage: „Welcher Vertrag betrifft Produkt Atlas, und wer ist dafür verantwortlich?“ Eine brauchbare Antwort muss jede Verbindung mit der richtigen Quelle belegen. Ein Absatz, in dem Atlas vorkommt, reicht dafür nicht. Auch eine extrahierte Kante kann falsch sein. Prüfe deshalb den zugrunde liegenden Text, bevor du die Antwort akzeptierst.

Vektorsuche kann manche dokumentübergreifenden Fragen bereits beantworten, insbesondere bei sinnvoller Textaufteilung und wiederholtem Abruf. Miss deshalb, ob der zusätzliche Graph bei euren tatsächlichen Fragen hilft. Unser Leitfaden zu Graph Engineering für KI-Agenten behandelt die grundsätzliche Architekturentscheidung. Hier geht es um den Betrieb von EdgeQuake.

Was „ein PostgreSQL“ in der Praxis umfasst

Zum gemeinsamen Datenspeicher gehört eine Anwendung aus mehreren Prozessen. Die Docker-Compose-Datei des Release-Tags definiert PostgreSQL, die Rust-API, ein Webfrontend und einen Migrationsdienst, der vor der API läuft. Die Veröffentlichung bietet Images für PostgreSQL 16, 17 und 18 mit den benötigten Erweiterungen. Bei einer gewöhnlichen verwalteten PostgreSQL-Instanz musst du prüfen, ob kompatible Versionen von pgvector und Apache AGE verfügbar sind.

Der Rust-Server besteht aus einer ausführbaren Datei. Frontend, optionaler Identitätsanbieter und lokale Modellserver haben eigene Laufzeitanforderungen. „Ein PostgreSQL“ beschreibt den Speicherort der Retrieval-Daten. Modellbetrieb, Backups und Upgrades bleiben Teil des Betriebsbudgets.

Lade für eine wiederholbare Evaluation die geprüfte Compose-Datei herunter und kontrolliere vor dem Start die gewählten Images:

mkdir edgequake-0.34.0
cd edgequake-0.34.0
curl -fsSL \
  https://raw.githubusercontent.com/raphaelmansuy/edgequake/v0.34.0/docker-compose.quickstart.yml \
  -o docker-compose.quickstart.yml
export EDGEQUAKE_VERSION=0.34.0
docker compose -f docker-compose.quickstart.yml config --images

Halte diese Version auch in deiner Deployment-Konfiguration fest. Andernfalls verwendet die Datei standardmäßig latest. Die Demo-Einstellungen binden veröffentlichte Ports an Loopback-Adressen und deaktivieren die Authentifizierung. Richte die Anmeldung ein, bevor du den Stack als gemeinsamen Wissensdienst verwendest. Der Abschnitt zur Authentifizierung unten verweist auf den notwendigen Compose-Override.

MCP-Gedächtnis: einlesen, Verarbeitung abwarten, Belege abrufen

Die MCP-Integrationsanleitung beschreibt das Gateway unter POST /mcp und den Alias /api/v1/mcp. Der Ablauf besteht aus folgenden Schritten:

1. Erstelle über die Oberfläche oder REST-API einen Workspace und erteile der vorgesehenen Identität Zugriff.
2. Mit Schreibberechtigung kannst du über eq_ingest Text übermitteln. Die Werkzeuge eq_upload_* verarbeiten hochgeladene Dateien.
3. Bewahre die zurückgegebene Aufgaben-ID auf und frage den Status mit eq_task_get ab. Das Dokument wird durchsuchbar, sobald die Aufgabe indexed meldet.
4. Nutze eq_search und anschließend eq_fetch mit view=toc, um die verfügbaren Belege zu sichten. Rufe die benötigten Textabschnitte oder Quellenbelege ab.
5. Lass den aufrufenden Agenten die Antwort formulieren und die Quellenverweise beibehalten. In einer neuen Unterhaltung muss er die Belege erneut abrufen.

Diese MCP-Werkzeuge liefern Belege, die der aufrufende Agent für seine Antwort verwendet. Die separate API zur Antwortgenerierung ist ein anderer Zugriffspfad. „Second Brain“ ist eine griffige Bezeichnung für dauerhaft gespeichertes, abrufbares Wissen. Daraus folgt weder eine automatische Erfassung jeder Unterhaltung noch die Korrektheit jeder Antwort.

Setze für einen ausschließlich lesenden Connector EDGEQUAKE_MCP_PROFILE=query in der Umgebung des API-Prozesses. Das Standardprofil control stellt zusätzlich Schreibwerkzeuge bereit; memory ist dessen Alias. Bei einer reinen Abfrage-Installation brauchst du einen Einlesepfad über die Oberfläche, die REST-API oder einen weiteren, gezielt konfigurierten Dienst.

Begrenze die Agentenberechtigungen auf den vorgesehenen Workspace

Die API-Key-Referenz unterscheidet edgequake:read, edgequake:query und edgequake:write. Neue Schlüssel erhalten standardmäßig Lese- und Abfrageberechtigungen. Erstelle den Schlüssel für eine eigene Identität, die nur den vom Agenten benötigten Workspaces angehört.

Nutze die Schnellstartanleitung zur Authentifizierung, um die Anmeldung zu aktivieren. Beim geprüften Compose-Deployment gehören dazu EDGEQUAKE_AUTH_ENABLED=true, EDGEQUAKE_DEV_MODE=false, ein starkes und dauerhaft gespeichertes JWT_SECRET sowie Zugangsdaten für die Ersteinrichtung. Zusätzlich ist ein Compose-Override nötig, der EDGEQUAKE_CORS_ORIGINS an die API weitergibt. Setze dort auch das MCP-Profil. Ein Export in der Host-Shell allein reicht bei dieser Compose-Datei nicht aus, um die Variable an den API-Prozess zu übergeben. SSO ist über Keycloak/OIDC verfügbar. Den Identitätsdienst und den Lebenszyklus der Konten musst du gesondert konfigurieren.

Ein Workspace-Header wählt den Kontext; die Autorisierungsprüfung muss den Zugriff begrenzen. Der Typ zur API-Key-Erstellung im Release-Tag nimmt einen Namen, Berechtigungen und ein optionales Ablaufdatum entgegen, aber keine Workspace-ID. Ein im Client eingestellter Standard-Workspace beschränkt den Schlüssel eines umfassend berechtigten Nutzers daher nicht automatisch auf diesen einen Workspace.

Prüfe mit demselben Schlüssel den Zugriff auf einen erlaubten und einen benachbarten Workspace. Wiederhole den Test ohne Workspace-Header und nach dem Entzug der Berechtigung. Beziehe neben der Suche auch Dokumentabrufe und Graphwerkzeuge ein. Unser separater Leitfaden zu RAG mit Quellenberechtigungen behandelt dokumentbezogene Zugriffsrechte aus vorgelagerten Systemen. Die Trennung von Workspaces allein belegt noch keine Übernahme dieser Quellenberechtigungen.

Eine anhand des Quellcodes geprüfte HTTP-Anfrage an einen authentifizierten Server

Sobald der Server eingerichtet und der fiktive Dokumentensatz indexiert ist, hinterlegst du Schlüssel, Mandanten-ID und Workspace-ID in deiner lokalen Umgebung. Diese Diagnoseanfrage folgt der HTTP-Transportvalidierung und dem Schema der Werkzeugargumente dieser Version. Zugangsdaten gehören nicht in eine versionierte Client-Konfiguration.

curl --fail-with-body -sS http://localhost:8080/mcp \
  -H "Authorization: Bearer $EDGEQUAKE_API_KEY" \
  -H "X-Tenant-ID: $EDGEQUAKE_TENANT_ID" \
  -H "X-Workspace-Id: $EDGEQUAKE_WORKSPACE_ID" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/call' \
  -H 'Mcp-Name: eq_search' \
  --data-binary @- <<'JSON'
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "eq_search",
    "arguments": {
      "query": "Which agreement affects Product Atlas, and who owns it?",
      "mode": "hybrid",
      "budget": "standard",
      "limit": 8
    }
  }
}
JSON

Dies ist eine Gateway-Diagnose, deren Aufbau anhand des Quellcodes geprüft wurde. Die Anfrage wurde nicht gegen einen laufenden Server ausgeführt. Ein gewöhnlicher MCP-Client führt zusätzlich den Initialisierungs-Handshake durch. Verwende HTTPS für ein entferntes Deployment. Prüfe die zurückgegebenen Belegreferenzen und Fehler, einschließlich JSON-RPC-error und MCP-isError. Eine HTTP-Antwort allein belegt keinen erfolgreichen Abruf.

hybrid kombiniert lokale und globale Graphsuche. Der Standardmodus mix ergänzt die Zusammenführung von Suchergebnissen und ein Reranking. Der folgende Benchmark verwendet Mix. Halte den Abfragemodus deshalb zusammen mit deinen Messergebnissen fest.

Prüfe die Transportkompatibilität des Clients, bevor du eine Bridge auswählst. Die stdio-Bridge im Release-Tag sendet die oben verwendeten Methoden- und Namensheader nicht mit und reicht auch den konfigurierten Standardmandanten nicht weiter. Dadurch ist ihre Eignung für Verbindungen in einer Umgebung mit mehreren Mandanten in dieser geprüften Fassung nur eingeschränkt belegt. Kontrolliere das tatsächlich installierte Paket und seine ausgehenden Anfragen, bevor du dich auf ein allgemeines npx-Konfigurationsbeispiel verlässt.

Für vollständig lokalen Betrieb musst du jede Modellrolle prüfen

EdgeQuake unterstützt Cloud-Anbieter und lokale Modellendpunkte. Die Referenz zu Workspace-Modellrollen hilft bei dieser Prüfung mehr als eine Liste von Anbieterlogos, weil sie die Datenwege sichtbar macht:

Die Rollendokumentation beschreibt den Rückfall auf Workspace- oder Serverstandards, wenn eine gespeicherte Anbieterverbindung nicht verwendet werden kann. Prüfe bei einem lokalen Deployment mit Ollama, LM Studio, MLX oder llama.cpp die Erreichbarkeit der Endpunkte und die tatsächlich gewählten Modelle je Rolle. Lass anschließend einen lokalen Endpunkt gezielt ausfallen und kontrolliere, ob ein anderer Anbieter die Anfrage erhält.

Auch das Modell des Agenten selbst ist ein mögliches Datenziel. Ein lokal betriebener Wissensspeicher kann Quellenpassagen an einen cloudbasierten MCP-Client zurückgeben. Beziehe diesen abschließenden Modellaufruf ein, wenn du beurteilst, ob der Ablauf deine Anforderungen an lokale Verarbeitung erfüllt.

Die Sicherheitsdokumentation für Modellanbieter beschreibt AES-256-GCM-Verschlüsselung für gespeicherte Anbieterschlüssel. Nach dem Speichern werden die Schlüssel nicht im Klartext zurückgegeben. Bewahre EDGEQUAKE_SECRETS_KEY sicher und dauerhaft auf: Bei Verlust oder Änderung lassen sich die gespeicherten Schlüssel nicht mehr entschlüsseln. Der interaktive Quickstart erzeugt bei jedem Lauf einen neuen Schlüssel, sofern noch keiner als Umgebungsvariable exportiert wurde. Die Verschlüsselung schützt gespeicherte Zugangsdaten. Der konfigurierte Anbieter verarbeitet weiterhin die an ihn gesendeten Anfragen.

Prüfe die PDF-Extraktion, bevor du dem Graphen vertraust

Die Anleitung zur PDF-Verarbeitung beschreibt Textextraktion und bildgestützte Verarbeitung für gescannte Seiten und komplexe Layouts. Teste eine echte Tabelle, eine gescannte Seite und ein Dokument mit einer geänderten Bauteilnummer. Prüfe den extrahierten Inhalt und seine Quellenverweise, bevor du die Antwort bewertest. Eine falsch gelesene Tabellenzeile kann zu einer überzeugend wirkenden, aber falschen Beziehung im Graphen werden.

EdgeQuake vs. LightRAG: Achte auf die Cache-Bedingungen

Der veröffentlichte Benchmark-Bericht des Projekts nennt die folgenden Werte. Sie stammen aus getrennten Messläufen des Projekts und wurden in die Release-Dokumentation übernommen.

Der Genauigkeitsvergleich verwendet denselben Dokumentensatz, dieselben Fragen, den Mix-Modus, Mistral Small und mistral-embed. Das 95-Prozent-Konfidenzintervall der Genauigkeitsdifferenz beträgt [-0.022, +0.034] und schließt null ein. Das belegt keine gleichwertige Retrieval-Qualität.

Im warmen Messlauf sind die Schritte für Schlüsselwörter, Embeddings und Antwortgenerierung jeweils mit einem Median von null Millisekunden ausgewiesen. Die 82 ms belegen deshalb nicht, wie lange eine neue Frage mit frischen Modellaufrufen bis zur Antwort braucht. Wiederholte Fragen können von diesem Cache-Pfad profitieren. Miss neue Fragen gesondert.

Eine aussagekräftige erste Evaluation passt in einen Workspace

Wir empfehlen einen kleinen, freigegebenen Dokumentensatz und Fragen, die konkrete Beziehungen zwischen benannten Entitäten erfordern. Legt vor dem Einlesen fest, welche Belege eine korrekte Antwort enthalten muss. Nehmt auch eine Frage auf, die sich mit den Dokumenten nicht beantworten lässt.

• Prüfe die vollständige Beziehungskette im Atlas-Beispiel und lies jede zitierte Passage nach.
• Stelle dieselben Fragen im gewählten Graphmodus und mit einer einfacheren Retrieval-Baseline.
• Erfasse die Latenz neuer und wiederholter Fragen, die Einlesedauer und die Modellkosten getrennt.
• Prüfe mit einer zweiten Identität die Workspace-Isolation, ungültige Zugangsdaten und entzogene Mitgliedschaften.
• Ändere einen Sachverhalt in einer Quelle, verarbeite sie erneut und suche nach widersprüchlichen oder veralteten Belegen.
• Stelle Datenbank und benötigte Secrets in einer Testumgebung wieder her und wiederhole den Abruf.

Mit edgequake doctor kannst du Konfiguration und Datenbankzustand prüfen. Führe die vorgesehenen Migrationen ausdrücklich aus, bevor eine aktualisierte API Anfragen bedient. Quellcodeprüfungen und ein fehlerfrei laufender Prozess unterstützen die Bewertung. Die Tests mit Dokumenten, Berechtigungen und Wiederherstellung zeigen, ob die Installation zu eurer Arbeit passt.

Eine EdgeQuake-Evaluation lohnt sich, wenn Dokumentbeziehungen und ein auf PostgreSQL ausgerichteter Betrieb zum Problem passen. Wenn ihr vor allem Coding-Entscheidungen zwischen IDEs teilen wollt, behandelt unsere Einrichtungsanleitung für mcp-memory-service diesen engeren Anwendungsfall. Für die Wahl zwischen einem eigenen Wissensdienst und einem bestehenden Produkt hilft der Entscheidungsleitfaden zu Individualsoftware und Standardsoftware.