ハクソク

世界を動かす技術を、日本語で。

Grafeo – Rustで構築された高速で軽量な埋め込み型グラフデータベース

2026年3月21日原文(grafeo.dev)

概要

  • Grafeo は高速かつ省メモリなグラフデータベース
  • Rust製コア による安全性と高パフォーマンス
  • 多言語・多データモデル対応 で柔軟な運用が可能
  • ベクトル検索・AI連携 など最新技術を搭載
  • 幅広い言語バインディング と容易な導入

Grafeoとは何か

  • LDBC Social Network Benchmark で最速クラスのグラフDB
  • インメモリDB よりも低いメモリフットプリント
  • Rust製コア、ベクトル化実行、適応チャンク、SIMD最適化による高速処理
  • ACIDトランザクション とMVCCスナップショット分離による信頼性
  • 埋め込み型・サーバ型 どちらも対応

多言語クエリ対応

  • GQL, Cypher, Gremlin, GraphQL, SPARQL, SQL/PGQ 対応
  • プロジェクトや開発者のスキルに合わせて選択可能
  • 各言語の特徴：
    • GQL ：ISO標準、宣言的パターンマッチ
    • Cypher ：Neo4j互換、直感的なASCIIアート構文
    • Gremlin ：Apache TinkerPop、トラバーサルベース
    • GraphQL ：スキーマ駆動、Web開発者向け
    • SPARQL ：RDF標準、セマンティックWeb
    • SQL/PGQ ：SQL:2023 GRAPH_TABLE対応

データモデルの柔軟性

  • LPG（Labeled Property Graph） と RDF（Resource Description Framework） 両対応
    • LPG ：ラベル・プロパティ付きノード＆エッジ、リッチデータ型
      • ソーシャルネットワークやアプリデータに最適
    • RDF ：主語-述語-目的語トリプル、W3C標準
      • セマンティックWeb、オントロジー、リンクドデータに最適

ベクトル検索・AI連携

  • HNSWベースの類似度検索、量子化（スカラー・バイナリ・プロダクト）対応
  • グラフトラバーサルと意味的類似性 の組み合わせが可能
  • LangChain, LlamaIndex, MCP などAIエコシステムと連携
  • WebAssembly対応 によるブラウザグラフ表示やノートブック連携

導入とバインディング

  • Python（PyO3）、Node.js/TypeScript（napi-rs）、Go（CGO）、C（FFI）、C#（.NET 8）、Dart、WebAssembly に対応
  • アプリ組み込み型 ：外部依存ゼロ
  • スタンドアロン型 ：REST APIとWeb UI
  • エッジデバイスから大規模クラスタ まで幅広い利用

クイックスタート例

  • Pythonサンプル
    • インメモリDB作成、ノード・エッジ追加、クエリ実行
    • uv add grafeoで導入
  • Rustサンプル
    • cargo add grafeoで導入
    • セッション作成、クエリ投入、結果取得

アーキテクチャの特徴

  • プッシュ型実行エンジン、モーセル駆動並列処理
  • カラムナストレージ と型特化圧縮
  • コストベースクエリ最適化、カーディナリティ推定
  • MVCCトランザクション、スナップショット分離
  • ゾーンマップ によるインテリジェントなデータスキップ

インストール方法

  • 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
  • C# ：dotnet add package GrafeoDB
  • Dart ：pubspec.yamlでgrafeo: ^0.5.21
  • WASM ：npm install @grafeo-db/wasm

ライセンス

  • Apache-2.0 License 採用

Hackerたちの意見

こういうの結構多いよね。Helix DBと比べてどうなの？それに、GraphQLでデータベースをクエリする理由って何？そもそもその目的で作られたわけじゃないのに。

AI/LLM駆動のサイクルで、同じようなグラフデータベースが25個も出てきてるよ。Rustで書くとHNで目立つからね。LadybugDBではそれをやらない理由があるんだ。もっと段階的なアプローチを探りたいし、クエリ言語も強く型付けされたサイファーだけに集中したい。 https://github.com/LadybugDB/ladybug/discussions/141

└

LadybugDBはこの25個のプロジェクトのうちの1つじゃないの？

このDB使ったことある人いる？どこから来たのか背景も知りたいな。コミット履歴を見ると、これはAIがコードしたプロジェクトだって明らかだよ。数ヶ月前に始まって、99%のコミットが1人の貢献者からで、その人は週に10万行のコードをコミットすることもあるみたい。（追記：最初の週には20万行のコード）LLMに反対ってわけじゃないけど、1人が週に10万行もコードを提出してるのを見ると、AIの出力に対して深く考えたりレビューしたりしてるとは思えない。経験上、AIに複雑なプロジェクトの大部分をコードさせると、非常に脆弱で、過剰に複雑で、考えが浅いものになりがちだって知ってる。磨かれたランディングページを持つAIのゴミプロジェクトを調査して痛い目にあったこともあるし、主張されているベンチマークが不適切に実行されたり、AIによって幻覚されたりすることもある。実際にこれを使ってる人いるの？それとも、AIを使って数ヶ月間問題に取り組むことで履歴書のポートフォリオプロジェクトを作ろうとしてるだけの個人的な実験なの？

└

同意するよ。ここ3ヶ月で新しいグラフデータベースがゼロから作られる爆発的な増加があったね。明らかに多くはLLMの助けを借りてる。https://gdotv.comで何をサポートするか決めるために業界の動向を追わなきゃいけなくて、正直最近はちょっと面倒になってきた。

└

これは、普通のアーキテクチャのバニラグラフデータベースにしてはかなりのコード量だね。気をつけるべきなのは、特にグラフデータベースエンジンは、繊細で洗練されたデザインなしに多くの鋭い部分を隠すことで知られているってこと。ここで必要なレベルの注意が払われているかは明らかじゃない。

└

早く出して反復するタイプの人にはちょうどいい感じだね。多分リファクタリングが必要なv0を54日で出すのは、開発者が本当にDBのバックグラウンドを持っていればそんなにクレイジーじゃないよ。オープンソースプロジェクトが3年も何も出さずにダラダラ続くのを見たことあるけど、それも必ずしも良いわけじゃないし。

└

LLMでコードされたデータベースを使うのは地獄みたいだね。メジャーなデータベースですら粗い部分があって使いづらいことがあるのに。

└

週に6桁の数字は、かなりの赤信号だね。そんなコミットログは、コード生成の雑さや一括フォーマットを意味することが多いし、たとえ一部が動いても、デザインやテストカバレッジ、長期的なメンテナンスの信頼性には全然自信が持てない。だから、そのDBを本番環境に置くなんて考えられないよ。

グラフデータベースの数に圧倒されてる？今週、新しいサイトを公開したよ。そこではグラフデータベースをリストアップしてカテゴライズしてるんだ。 https://gdb-engines.com

└

LLMを使ってリストを生成したの？

真面目な質問なんだけど、実際に信頼できるグラフデータベースってある？生産環境で合理的な規模で使えるもので、ベンダーとしてもオープンソースとしても手に入るやつ。例えば、MetaのTAOみたいなやつじゃなくて。

Hacker Newsで議論の続きを見る