Grafeo – schnelle und leichtgewichtige eingebettete Graphdatenbank

 (grafeo.dev)
2 Punkte von GN⁺ 2026-03-23 | 1 Kommentare | Auf WhatsApp teilen
  • Eine in Rust entwickelte Hochleistungs-Graphdatenbank, die sowohl im eingebetteten als auch im Server-Modus läuft und dabei einen geringen Speicherverbrauch beibehält
  • Unterstützt sowohl das Modell Labeled Property Graph (LPG) als auch RDF-Tripel und eignet sich damit für ein breites Spektrum von sozialen Netzwerken bis zum semantischen Web
  • Unterstützt verschiedene Abfragesprachen wie GQL, Cypher, Gremlin, GraphQL, SPARQL, SQL/PGQ, sodass Entwickler eine große Auswahl haben
  • Bietet einen vollständigen Funktionsumfang mit HNSW-basierter Vektorsuche, ACID-Transaktionen, MVCC-Snapshot-Isolation, mehrsprachigen Bindings und mehr
  • Integriert sich mit KI-Frameworks wie LangChain, LlamaIndex, MCP und unterstützt damit die Verbindung von Graphdaten und KI-Anwendungen

Überblick über Grafeo

  • Grafeo ist eine in Rust entwickelte Hochleistungs-Graphdatenbank, die sowohl im eingebetteten als auch im Server-Modus arbeitet und dabei einen geringen Speicherverbrauch beibehält
  • Erzielte Spitzenleistung im LDBC Social Network Benchmark und unterstützt vektorisierte Ausführung, adaptives Chunking und SIMD-optimierte Operationen
  • Unterstützt beide Datenmodelle, Labeled Property Graph (LPG) und RDF-Tripel, und eignet sich dadurch für verschiedenste Domänen vom sozialen Netzwerk bis zum semantischen Web
  • Bietet einen vollständigen Funktionsumfang einschließlich ACID-Transaktionen, MVCC-basierter Snapshot-Isolation, mehrsprachigen Bindings und einem KI-integrierten Ökosystem

Hauptmerkmale

  • Hochleistungsarchitektur

    • Geschrieben als kernseitige Engine auf Rust-Basis ohne C-Abhängigkeiten; optional können jemalloc/mimalloc sowie TLS-C-Bibliotheken verwendet werden
    • Umfasst eine Push-basierte Ausführungs-Engine, Parallelverarbeitung auf Morsel-Ebene, spaltenorientierten Speicher, typbasierte Komprimierung und einen kostenbasierten Query-Optimizer
    • Unterstützt effiziente Abfragen durch Data Skipping mit Zone Maps

  • Unterstützung mehrerer Abfragesprachen

    • Unterstützt GQL, Cypher, Gremlin, GraphQL, SPARQL und SQL/PGQ
    • Je nach Projektcharakter und Erfahrung der Entwickler kann eine passende Sprache gewählt werden
    • GQL bietet deklaratives Pattern Matching nach ISO-Standard, Cypher ein mit Neo4j kompatibles ASCII-Art-Pattern, Gremlin einen traversierungsorientierten Stil auf Basis von Apache TinkerPop
    • GraphQL unterstützt sowohl LPG als auch RDF, SPARQL ist die standardisierte RDF-Abfragesprache des W3C, SQL/PGQ unterstützt die GRAPH_TABLE-Syntax aus SQL:2023

  • Datenmodelle

    • Das LPG-Modell verwendet eine Struktur aus Knoten und Kanten mit Labels und Eigenschaften und unterstützt Eigenschaften mit verschiedenen Datentypen
    • Das RDF-Modell verwendet die Tripelstruktur Subjekt-Prädikat-Objekt und ermöglicht mit SPO/POS/OSP-Indizes effiziente Abfragen
    • RDF ist durch W3C-Standardkonformität für semantisches Web, Ontologien und Linked Data geeignet

  • Vektorsuche

    • Bietet HNSW-basierte Ähnlichkeitssuche und unterstützt skalare, binäre und Produktquantisierung
    • Kann Graphdurchsuchung mit semantischer Ähnlichkeitssuche kombinieren

  • Eingebettet und eigenständig ausführbar

    • Kann ohne externe Abhängigkeiten direkt in Anwendungen eingebettet oder als eigenständiger Server mit REST API und Web-UI betrieben werden
    • Lässt sich von Edge-Geräten bis zu großen Produktionsclustern skalieren

  • Transaktionen und Speichersicherheit

    • Gewährleistet vollständige ACID-Transaktionen mit MVCC-basierter Snapshot-Isolation
    • Unterstützt stabile nebenläufige Verarbeitung durch Rusts Speichersicherheit und das Design der fearless concurrency

  • Mehrsprachige Bindings

    • Unterstützt Python (PyO3), Node.js/TypeScript (napi-rs), Go (CGO), C (FFI), C# (.NET 8 P/Invoke), Dart (dart:ffi) und WebAssembly (wasm-bindgen)
    • So kann dieselbe Grafeo-Engine in unterschiedlichen Sprachumgebungen genutzt werden

  • Ökosystem und Integrationen

    • Integriert sich mit KI-Frameworks wie LangChain, LlamaIndex und MCP
    • Bietet interaktive Notebook-Widgets, browserbasierte WebAssembly-Graphvisualisierung, eigenständigen Server mit Web-UI und Benchmarking-Tools

Installation und Einstieg

  • Installationsbefehle

    • Python: uv add grafeo
    • Node.js: npm install @grafeo-db/js
    • Go: go get github.com/GrafeoDB/grafeo/crates/bindings/go
    • Rust: cargo add grafeo
    • .NET: dotnet add package GrafeoDB
    • Dart: grafeo: ^0.5.21
    • WebAssembly: npm install @grafeo-db/wasm

  • Schnellstartbeispiele

    • Im Python-Beispiel wird nach dem Erzeugen einer In-Memory-Datenbank mit INSERT- und MATCH-Anweisungen Knoten und Kanten hinzugefügt und Beziehungen abgefragt
    • Im Rust-Beispiel wird die Datenbank mit GrafeoDB::new_in_memory() erstellt und dieselbe Abfrage über eine Session ausgeführt

Lizenz

  • Grafeo wird unter der Apache-2.0-Lizenz veröffentlicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-23
Hacker-News-Kommentare

  • Ich frage mich, ob Grafeo den LDBC-Benchmark implementiert hat.
    Ich würde es gern mit anderen Graph-Datenbanken vergleichen. Besonders die Performance bei OLAP-Abfragen interessiert mich.
    Verwandter Beitrag: Neo4j alternatives in 2026

  • Wir haben kürzlich eine Cypher-Syntax für gfql veröffentlicht.
    Das ist die erste OSS CPU/GPU-basierte Cypher-Query-Engine, die direkt auf DataFrames ausgeführt werden kann.
    Sie wird vor allem zusammen mit skalierbaren DBs wie Databricks oder Splunk für Sicherheit, Betrugserkennung, Ereignisanalyse und ML+AI-Embedding-Pipelines genutzt.
    Ohne DB-Installation kann sie auf einer einzelnen GPU mehr als 1 Milliarde Kanten pro Sekunde verarbeiten und lässt sich direkt auf Apache-Arrow- oder Parquet-Daten anwenden.
    Siehe die GFQL-Benchmark-Dokumentation.
    Der vektorisierte Core erfüllt bereits mehr als die Hälfte der TCK, und wir ergänzen derzeit die komplexeren Teile.
    Sie wird bereits produktiv bei NATO, Banken, der US-Regierung und anderen Organisationen eingesetzt und ist nun Open Source, damit andere Entwickler oder LLMs sie direkt nutzen können.

  • Ich frage mich, ob jemand diese DB (Grafeo) kennt.
    Wenn man sich die Commit-Historie ansieht, wirkt es fast wie ein von KI geschriebenes Projekt. Eine Person hat pro Woche 100.000 bis 200.000 Zeilen committed.
    In solchen Fällen war die Codequalität oft schwach oder übermäßig komplex.
    Mich würde interessieren, ob das jemand tatsächlich nutzt oder ob es nur ein KI-Portfolio-Experiment ist.

    • Ich bin derjenige, der Grafeo gebaut hat. Warum es sich überall verbreitet, weiß ich nicht, aber ich kann Fragen beantworten.
      Die frühe Version war eine Neuaufbereitung meiner selbst gebauten lokalen Graph-DB namens Graphos.
      Engine und Core, Python-Bindings und Tests habe ich von Hand geschrieben, die Dokumentation und ein Teil der Konfiguration wurden von KI erzeugt.
      Die von KI erzeugten Teile habe ich geprüft, aber sie sind noch nicht auf Produktionsniveau.
      Auslöser waren meine Unzufriedenheit mit Neo4j und Gespräche mit Hännes von DuckDB.
      Weil mir der Speicherverbrauch von LadybugDB zu hoch war, habe ich es selbst gebaut, und aktuell nutze ich es persönlich zufriedenstellend.
      Es gibt kein kommerzielles Ziel, ich habe es als Open Source veröffentlicht und freue mich über Mitwirkende.
    • Für die typische Struktur einer Graph-DB ist das schon eine große Codebasis.
      Bei einer Graph-Engine ist detailliertes Design wichtig, deshalb mache ich mir Sorgen um die Designqualität im Detail.
    • Eine von LLMs geschriebene DB zu benutzen, klingt nach einem Albtraum. Selbst große DBs sind schon schwer genug zu handhaben.
    • In den letzten drei Monaten ist die Zahl der von LLMs erzeugten Graph-DBs explodiert.
      Auch auf gdotv.com wird es für mich immer schwieriger zu entscheiden, welche davon ich unterstützen soll.
    • 100.000 Commit-Zeilen pro Woche sind eine rote Flagge. Meist handelt es sich um generierten Code oder Formatierung, und die Zuverlässigkeit von Design und Tests könnte entsprechend gering sein.

  • Es gibt so viele Graph-DBs, dass ich zur Orientierung die neue Website gdb-engines.com gebaut habe.
    Dort werden die einzelnen DBs klassifiziert und geordnet.

    • Es wäre gut, wenn die Tabelle zwischen eingebettet und Server-basiert unterscheiden würde.
    • Ich frage mich, ob diese Liste vielleicht mit LLMs generiert wurde.

  • Ich frage mich, ob es tatsächlich Graph-Datenbanken gibt, denen man im Produktionsmaßstab vertrauen kann.
    Mich interessieren Open-Source- oder Vendor-Produkte, ausgenommen Spezialfälle wie Meta TAO.

    • Ich möchte einer direkten Antwort lieber ausweichen, aber die Wahl einer Graph-DB ist wirklich schwierig.
      In meinem FOSDEM-2025-Vortrag behandle ich dieses Thema.
    • Nach Open-Source-Maßstäben sind JanusGraph, DGraph, Apache AGE, HugeGraph, MemGraph, ArcadeDB geeignet.
    • Ich leite die Entwicklung von TypeDB. Es verwendet kein Cypher, funktioniert aber auch in großen Produktionsumgebungen gut.
      Die meisten OSS-DBs folgen in gewissem Maß einem Open-Core-Modell.
    • Das Graph-System von Facebook besteht nicht nur aus TAO, sondern aus einem größeren Ökosystem.
      Verwandter Beitrag: A brief history of graphs at Facebook
    • Ich habe auf gdotv.com Dutzende Graph-DBs integriert, und die meisten sind produktionsreif.
      Besonders JanusGraph ist zwar alt, wird aber in Unternehmen weiterhin beständig eingesetzt.

  • Inzwischen gibt es 25 Graph-DBs, die auf den aktuellen AI/LLM-Boom aufspringen.
    Wenn man sie in Rust schreibt, bekommt man auf HN Aufmerksamkeit, aber LadybugDB hat sich bewusst dagegen entschieden.
    Stattdessen wollen wir uns auf schrittweise Verbesserung und stark typisiertes Cypher konzentrieren.
    Verwandte Diskussion: LadybugDB Discussion #141

    • Ich frage mich, ob LadybugDB nicht auch eines dieser 25 Projekte ist.
    • Das ist eine gute Entscheidung, denn nicht die Sprache, sondern der Reifegrad des Produkts bringt Kunden.
    • Sprachdebatten sind ermüdend, aber Rust hat bei der DB-Entwicklung reale Vorteile in Bezug auf Nebenläufigkeit und Vermeidung von Datenkorruption.
      Man sollte das nicht als bloßes „Gefühl“, sondern auf technischer Grundlage bewerten.

  • Grafeo ist ganz klar ein mit KI-Unterstützung geschriebenes Projekt.
    Es hat viel Code, wirkt aber nicht wie ein simples KI-Erzeugnis, und auch das Design ist eigenständig.
    Die JS-Tests sehen vollständig KI-generiert aus, und die Qualität einiger Sub-Repos schwankt stark.
    Wegen der Apache-2.0-Lizenz und des Funktionsumfangs ist es interessant, scheint aber mehr Maintainer zu brauchen.

  • Mich würde interessieren, worin der Unterschied zu Helix DB besteht.
    Und ich frage mich, warum man ausgerechnet mit GraphQL eine DB abfragen sollte.

  • Die Formulierung „mit graph-bench den LDBC-Benchmark getestet“ klingt fast wie ein unabhängiger Benchmark.
    Wenn es ein selbst gebautes Tool ist, sollte man das klar sagen und Feedback einholen, damit sich auch andere Projekte fair vergleichen lassen.

    • Wahrscheinlich wurde auch dieser Satz automatisch von KI geschrieben.
      Das ist ein typisches Muster der KI-generierten Codebasen, die in letzter Zeit oft auf HN auftauchen.
      Bei mehr als 100.000 Commit-Zeilen pro Woche ist es unwahrscheinlich, dass ein Mensch den Codeinhalt wirklich vollständig versteht.

  • Ich habe Grafeo und die zugehörige Bibliothek grafeo_langchain zusammen mit einem lokalen Ollama-Modell ausprobiert.
    Das Ergebnis war ein halber Erfolg.
    Ich mag und nutze weiterhin die Python-basierte Kuzu-Graph-DB.

    • Mich würde interessieren, ob du Kuzu auf gdotv.com ausprobiert hast.
      Kuzu wird nicht mehr weiterentwickelt, bleibt aber stabil, deshalb behalten wir den Support bei.
      Auch eine Migration zu LadybugDB (dem Haupt-Fork) ist einfach, daher könnte sich das lohnen.