FalkorDBとは｜GraphRAGの土台になるグラフDBエンジンを疎行列・インデックス・ライセンスから解説

グラフデータベースの記事は「ノードと辺でデータを表現できます」で終わりがちだが、実際に選定するときに効いてくるのは、そのエンジンが何を担当して、何を担当しないのかという線引きの方だ。FalkorDBは、テキストやコードからノードと辺を切り出す仕事を一切しない。切り出した結果を受け取って、保存し、索引を張り、openCypherで探索させる——その一点に特化したエンジンである。

RAG全体の設計とストレージ選定の流れは RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ にまとめている。本記事はその中の「グラフを置く場所」に絞り、FalkorDBのソースと公式リポジトリから読み取れる事実だけで構成する。

FalkorDBとは——グラフを「作る側」ではなく「置く側」のエンジン

FalkorDBのリポジトリdescriptionは「A super fast Graph Database uses GraphBLAS under the hood for its sparse adjacency matrix graph representation. Our goal is to provide the best Knowledge Graph for LLM (GraphRAG).」となっている。GitHubのtopicsには graph-database graphrag knowledge-graph developer-tools などが並ぶ。

当サイトでは、コードやドキュメントをナレッジグラフに変換するツールを何本か扱ってきた。Graphify入門：コード・ドキュメント・画像をナレッジグラフ化し、AIの検索トークンを71.5倍削減するOSS はtree-sitterのAST解析とセマンティック解析でコードをグラフ化するツールであり、LightRAG とは｜知識グラフ×デュアルレベル検索の仕組みとストレージ選定 は知識グラフとデュアルレベル検索を組み合わせるRAGフレームワークだ。

これらはいずれも「元データからノードと辺を作り出す」側にいる。FalkorDBの仕事はその後段にある。抽出済みのノードと辺を受け取り、ディスクとメモリ上に保持し、MATCH (a)-[:KNOWS*1..3]->(b) のようなクエリに答える。抽出のロジックもLLM呼び出しも持っていない。

この線引きは、選定するときに実際的な意味を持つ。抽出ツールを乗り換えてもエンジンはそのまま使えるし、逆にエンジンを乗り換えても抽出パイプラインは基本的に残る。両者を1つの製品で兼ねているOSSもあるが、FalkorDBは明確に後者だけを引き受ける。

実測したリポジトリの数字

記事執筆時点（2026-08-03 JST）にGitHub APIで取得した実測値は次のとおり。

・Star 4,874 / Fork 412 / コントリビューター 65人
・コミット総数 2,328（per_page=1 のページネーション最終ページ番号から算出）
・言語バイト数：C 5,123,977 / Python 2,110,972 / Gherkin 1,485,210 / C++ 515,192 / Shell 96,298
・最新リリース v4.20.1（2026-07-15公開）、その前が v4.20.0（2026-07-13）
・未クローズ 764件の内訳は Issue 616件 / PR 148件（GitHubの open_issues_count はPRを含むため分解した）
・Docker Hub の pull_count は 882,903（falkordb/falkordb）

Gherkinが1.48MBある点は、振る舞い駆動のテスト記述（.feature ファイル）がかなりの分量で維持されていることを示す。C実装のデータベースとしては、テスト資産の比重が高い部類だ。

疎行列とGraphBLAS——FalkorDBが採用した内部表現をdeps/から読む

FalkorDBの中心的な主張は「プロパティグラフのクエリ可能なデータベースとして、隣接行列の表現に疎行列を、クエリ実行に線形代数を使う」という点にある。これは実装を見ると確認できる。

deps/ 配下には GraphBLAS がディレクトリとして同梱されている。同梱されているChangeLogの先頭は「July 31, 2026, version 10.4.0」で、SuiteSparse:GraphBLASのかなり新しい版が取り込まれていることが分かる。GraphBLASは、グラフアルゴリズムを行列演算として表現するための標準API仕様とその実装であり、「隣接行列に対する疎行列積で1ホップ先を求める」という考え方を土台にしている。

.gitmodules に登録されているsubmoduleは以下のとおりで、それぞれ役割が異なる。

・deps/LAGraph——GraphBLAS上に構築されたグラフアルゴリズム集
・deps/RediSearch——ただし参照先は本家ではなく FalkorDB/RediSearch のフォーク。全文検索・ベクトル検索の索引実装がここに寄っている
・deps/quickjs——Bellard氏の軽量JavaScriptエンジン
・deps/oniguruma / deps/utf8proc——正規表現とUnicode処理
・deps/libcsv / deps/libcurl——CSV読み込みとHTTPクライアント
・deps/rax / deps/xxHash——基数木とハッシュ

QuickJSが入っている理由は、コマンド一覧を見ると腑に落ちる。後述する GRAPH.UDF（ユーザー定義関数）が登録されており、src/commands/cmd_udf.c が実装として存在する。JavaScriptエンジンを同梱してユーザー定義関数を動かす構成になっている。

C実装の中に入り始めたRust

見落とされやすいが、リポジトリのルートには Cargo.toml と Cargo.lock がある。中身は次のとおりで、ワークスペースのメンバーは1つだけだ。

[workspace]
resolver = "2"
members = [
    "deps/FalkorDB-core-rs",
]

つまり主要言語はCのままだが、deps/FalkorDB-core-rs としてRustのコアが同居している。さらに同組織は falkordb-rs-next-gen（★27・2025-02-27作成・2026-07-29更新）を「The next-generation, high-performance FalkorDB engine rewritten in Rust」として別途公開している。ここから読み取れるのは、Rustへの移行が「別リポジトリでの全面書き直し」と「本体への段階的な取り込み」の二正面で進んでいるという状況だ。ただし、どちらがいつ既定の実装になるのかは公開情報から確認できなかったため、現時点では併存しているという事実にとどめる。

インストールと最初のクエリ——Dockerで動かす手順

FalkorDBはRedisのモジュールとしてロードされる。READMEには「FalkorDB is hosted by Redis, so you’ll first have to load it as a Module to a Redis server」とあり、最新版にはRedis 7.4が必要と注記されている。

最短の起動手順はREADMEに載っているDockerコマンドだ。6379 がデータベース、3000 が付属のブラウザUIのポートになる。

docker run -p 6379:6379 -p 3000:3000 -it --rm \
  -v ./data:/var/lib/falkordb/data falkordb/falkordb

起動したら http://localhost:3000 を開くとFalkorDB Browserが立ち上がる。冒頭の動画とこの後のスクリーンショットは、このブラウザUIの画面だ。

既存のRedisにモジュールとして読み込ませる場合は、redis.conf に loadmodule を書くのがREADMEの推奨だ。

loadmodule /path/to/module/src/falkordb.so

コマンドラインから直接渡すこともできる。READMEは MODULE LOAD について「dangerous command であり、セキュリティ上の理由で将来ブロックまたは非推奨になる可能性がある」と注記しているので、起動時ロードを選ぶのが無難だ。

redis-server --loadmodule /path/to/module/src/falkordb.so

クエリはRedisプロトコルの上に乗るため、任意のRedisクライアントから叩ける。redis-cli なら次の形になる。

redis-cli GRAPH.QUERY social \
  "CREATE (:person {name: 'roi', age: 33, gender: 'male', status: 'married'})"

この「Redisクライアントがそのまま使える」という性質は、導入時の摩擦を大きく下げる。専用ドライバを入れずに既存の運用ツールから疎通確認できるからだ。公式クライアントを使う場合、PythonならPyPIの FalkorDB パッケージから次のように書ける（READMEのMotoGP例を要約したもの）。

from falkordb import FalkorDB

db = FalkorDB(host='localhost', port=6379)
g = db.select_graph('MotoGP')

g.query("""CREATE (:Rider {name:'Valentino Rossi'})-[:rides]->(:Team {name:'Yamaha'}),
                  (:Rider {name:'Dani Pedrosa'})-[:rides]->(:Team {name:'Honda'})""")

res = g.query("""MATCH (r:Rider)-[:rides]->(t:Team)
                 WHERE t.name = 'Yamaha'
                 RETURN r.name""")
print(res.result_set)

macOSで「Dockerなし」を狙うと踏む穴

同組織は falkordblite（★61）を「Embedded, zero-config FalkorDB for Python, start a local graph database with no setup」として公開している。Dockerを使わずにPythonから直接起動できるなら手軽なので、実際に試した。

Apple Silicon（M2）・Python 3.14の環境で pip install falkordblite を実行すると、ソースからビルドが走り falkordblite-0.10.0-cp314-cp314-macosx_14_0_arm64.whl というwheelが生成される。ファイル名はmacOS ARM64向けを主張している。ところが、同梱される共有ライブラリを調べると中身が食い違っていた。

$ file .../site-packages/redislite/bin/falkordb.so
ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux),
dynamically linked, BuildID[sha1]=77d595ff..., stripped

wheelのタグは macosx_14_0_arm64 なのに、実体はLinux x86-64のELFバイナリ（51,475,528バイト）だった。同梱の redis-server（v8.6.2）自体はmacOSネイティブで起動するものの、このモジュールをロードさせるとdlopenが not a mach-o file で失敗し、サーバーは起動を中止する。

なおパッケージのimport名は falkordblite ではなく redislite で、実体はredisliteをベースにFalkorDBを組み込んだフォークだった。macOS上で手軽に試す用途では現状Dockerの方が確実、という結論になる。Linux x86-64であればこのバイナリはそのまま使えるはずだが、そちらは未検証なので断定はしない。

マルチテナントと3種のインデックス——GraphRAGでFalkorDBが効く理由

READMEの見出しは「Ultra-fast, Multi-tenant Graph Database」で、その下に「Powering Generative AI, Agent Memory, Cloud Security, and Fraud Detection」と続く。このうちエージェント記憶やGraphRAGの文脈で効くのは、マルチテナント性とインデックスの種類だ。

コマンドは17本

src/module.c（383行）を読むと、登録されている GRAPH.* コマンドは17本で、RedisModule_CreateCommand の呼び出し回数も17回で一致する。内訳は次のとおり。

GRAPH.LIST があることが、マルチテナント性の実装的な裏づけになる。FalkorDBでは1つのRedisインスタンスの中に名前の異なるグラフを複数持てる。GRAPH.QUERY social ... と GRAPH.QUERY MotoGP ... は別々のグラフを触る。エージェントごと・テナントごとに独立したグラフを切る運用は、この構造の上に成り立つ。

インデックスはRANGE / FULLTEXT / VECTOR

src/commands/index_operations.c を読むと、インデックスの型は3種類が定義されている。

case CYPHER_INDEX_TYPE_RANGE:    *idx_type = INDEX_FLD_RANGE;
case CYPHER_INDEX_TYPE_FULLTEXT: *idx_type = INDEX_FLD_FULLTEXT;
case CYPHER_INDEX_TYPE_VECTOR:   *idx_type = INDEX_FLD_VECTOR;

同ファイルのコメントには、対象がノードだけでないことが明示されている。

・// CREATE FULLTEXT INDEX FOR (n:N) ON (n.name)
・// CREATE VECTOR INDEX FOR ()-[e:R]-() ON (e.name)
・// DROP VECTOR INDEX FOR ()-[e:R]-() ON (e.name)

つまりベクトルインデックスはノードだけでなく関係（辺）にも張れる。「この引用関係そのものの埋め込み」で近傍検索する、といった設計が型として用意されていることになる。

GraphRAGの文脈でこれが効くのは、検索の2つのモードを同じデータベースに置けるからだ。埋め込みの近傍検索で入口のノードを見つけ、そこからグラフ探索で関連する事実をたどる——という流れを、別々のベクトルDBとグラフDBに分けずに済む。データの二重管理と同期のズレを避けられる点が実装上の利点になる。

クエリが処理される流れ

ここまでの部品を、1つのクエリが通る順に並べると次のようになる。

GRAPH.EXPLAIN があるおかげで、実際にどの経路が選ばれたかは実行前に確認できる。多段の可変長探索（[:KNOWS*1..3] のような書き方）を投げる前に計画を見ておくのは、グラフDBでは特に効果が大きい。

ライセンスはSSPLv1——サーバーとクライアントで条件が違う

ここは選定の可否を分けうる部分なので、事実だけを正確に置く。

GitHub APIが返すライセンス欄は NOASSERTION（判定不能）だが、これは自動判定の結果にすぎない。実体は明確で、READMEに「This project is licensed under the Server Side Public License v1 (SSPLv1)」と書かれており、LICENSE.txt（30,582バイト）の冒頭は次のようになっている。

                     Server Side Public License
                     VERSION 1, OCTOBER 16, 2018

                    Copyright © 2018 MongoDB, Inc.

MongoDBのSSPL v1本文がそのまま置かれている。SSPLで実務上いちばん問題になるのは第13条で、原文の見出しは「Offering the Program as a Service.」だ。要旨は「プログラムまたはその改変版の機能をサービスとして第三者に提供する場合、Service Source Codeをこのライセンスの下で無償のネットワークダウンロードによって全員に利用可能にしなければならない」というもので、リモートから機能を使わせる形態を広く含む書き方になっている。

SSPLはOSI（Open Source Initiative）の承認を受けたライセンスではない。したがって「オープンソース」という語を厳密な定義で使う組織では、扱いを社内で確認しておく必要がある。自社サービスの内部でデータベースとして使う分には通常問題にならないが、FalkorDBの機能自体をサービスとして外部提供する構成では第13条を読む必要が出てくる。ここは法務判断の領域なので、本記事では条文の所在を示すにとどめる。

一方、公式クライアントは条件が大きく違う。READMEのクライアント表と各リポジトリのライセンス表記を突き合わせると次のようになる。

アプリケーション側に取り込むコード（クライアント）は寛容型で、制約がかかるのはサーバーバイナリの側だけ、という構成になっている。この区別を押さえておくと、検討時の議論が具体的になる。

RedisGraphからの系譜とv4.20の変更点

FalkorDBのリポジトリ作成日は2023-07-20だが、コミット履歴はそこで始まっていない。

per_page=1 でページネーションを最後まで辿ると、総コミット数は2,328で、最古のコミットは2018-02-21の「Insertion time should not be effected by graph size」（作者 swilly22）だった。2018-03-16には「Import old code base」というコミットもある。swilly22はRedisGraphの原作者であり、deps/RediSearch の参照先がFalkorDBのフォークであること、READMEの「Additional Clients」表に redisgraph-rb redisgraph-go NRedisGraph といった旧RedisGraph向けクライアントが互換として並んでいることも、同じ系譜を裏づける材料になる。

なお当サイトでは、同じくRAG基盤を扱う RAGFlowとは｜高精度な文書解析でRAGを組むOSSエンジンの使い方・Docker導入・GraphRAG も解説している。こちらは文書解析からRAGパイプラインまでを含む上位レイヤーの製品で、FalkorDBとは守備範囲が異なる。

v4.20.0でBoltサポートが削除された

2026-07-13公開のv4.20.0のリリースノートには、「🔧 Changes」の項に remove bolt support が入っている。該当PRは #2170で、2026-07-08にマージ済み。変更規模は39ファイル・26行追加・5,176行削除で、現在のmasterの src 配下にboltディレクトリは存在しない。

BoltはNeo4jが用いるワイヤプロトコルで、これに対応していると一部のグラフ可視化ツールやドライバがそのまま繋がる。その入口が閉じたため、Bolt前提のツールチェーンを組む計画がある場合は先に確認が必要になる。逆に言えば、FalkorDBはRedisプロトコル一本に寄せる方向を選んだということでもある。

同じv4.20.0には可変長探索（Variable Length Traversal）のセマンティクス変更（PR #2156）や、最短経路 algo.SPpaths とDijkstraの性能改善（PR #2163・#2173）も含まれる。セマンティクスの変更はクエリの結果自体に影響しうるので、既存環境からのアップグレード時は該当PRを読んでおきたい。

続くv4.20.1（2026-07-15）はバックポート1件のみの小規模リリースだった。リリース間隔は2026年に入ってからおおむね月次で、v4.18.9（06-03）→v4.18.10（06-10）→v4.18.11（06-24）→v4.20.0（07-13）→v4.20.1（07-15）と刻まれている。

類似ツールとの比較と、選ぶ・選ばない基準

同じ「グラフを扱う」でも、層と設計思想が違えば比較の軸も変わる。当サイトで扱ってきたものを含めて整理する。

※ 各項目は2026-08-03にGitHub APIと公式READMEで再確認した値。HelixDBは HelixDB/helix-db（★5,693・Rust・Apache-2.0）で、READMEの自己紹介は「a graph-vector database for knowledge graphs and AI memory. Built from scratch in Rust.」。クエリ言語については本記事では確認していないため空欄にしている。Graphify・LightRAG・RAGFlowの詳細は上記リンク先を参照。性能の優劣は環境とワークロードに依存するため、ここでは設計上の位置づけのみを並べている。

比較表の一行目と二行目——FalkorDBとHelixDB——が、この記事でいう「エンジン層」に当たる。両者は同じ層にいながら設計判断が対照的だ。FalkorDBはRedisのモジュールとして動き、openCypherという既存の標準とRedisプロトコルに寄せる。HelixDBはRustで書かれた単体のデータベースで、READMEによればグラフ＋ベクトルを主データモデルとしつつKV・ドキュメント・リレーショナルも扱うとしている。既存のRedis運用資産やCypherの知識を活かせるかどうかが、選択の分かれ目になりやすい。

ライセンス条件も両者で異なり、FalkorDBがSSPLv1であるのに対しHelixDBはApache-2.0だった（2026-08-03時点）。この種の値は変わるので、検討時には必ず各リポジトリのLICENSEを自分で確認してほしい。

選ぶ理由になりやすい点

・openCypherに寄せている。Cypher系の記法を知っていれば学習コストが低い。ただしBolt互換は上記のとおりv4.20.0で外れている
・Redisクライアントがそのまま使える。専用ドライバなしで疎通確認でき、既存の監視・運用ツールも一部流用できる
・1インスタンスに複数グラフ。テナントやエージェント単位でグラフを分ける設計に素直に乗る
・ベクトル索引がエンジン内にある。グラフ探索と近傍検索を1つのデータベースに寄せられる
・公式のGraphRAG-SDK（★981・Apache-2.0）がある。組織としてGraphRAG用途を主要なユースケースに位置づけている

慎重に検討すべき点

・SSPLv1。OSI承認ライセンスではなく、サービス提供形態では第13条の確認が要る
・Redis 7.4以上が前提。READMEに最新版の要件として明記されている。既存Redisのバージョンによっては先に更新が必要
・Boltが外れた（v4.20.0）。Bolt前提の可視化ツールやドライバを組み込む計画があるなら影響する
・未クローズIssueが616件。活発である裏返しでもあるが、規模としては小さくない
・macOSでのDockerなし導入は現状つまずく。falkordblite 0.10.0のwheelの問題は上で見たとおり

周辺リポジトリで確認できるAI連携

「GraphRAGの土台」という位置づけが宣伝文句だけでないことは、同組織の公開リポジトリからも確認できる。

・GraphRAG-SDK（★981・Apache-2.0・Python）——GraphRAGアプリを構築するためのSDK
・QueryWeaver（★1,056・AGPL-3.0・Python）——自然言語をSQLに変換するText2SQLツール
・FalkorDB-MCPServer（★38・MIT・TypeScript）——LLMとFalkorDBを繋ぐMCPサーバー
・code-graph（★330・MIT）——GraphRAG-SDKとFalkorDBを使ったコードグラフのデモ
・skills（★22・MIT）——Claude Code向けのスキル集。cypher-skills ingestion-skills operations-skills udf-skills の4ディレクトリ構成で、SKILL.md にはCypherの書き方やDocker運用の手順が収録されている

最後のskillsリポジトリは、データベースベンダーがコーディングエージェント向けの手順書を公式に配る例として興味深い。中身は「redis-cliを使う」「Cypherは GRAPH.QUERY に引用符付き文字列で渡す」「キャッシュ効率と安全性のためにパラメータ化クエリを使う」といった規約から始まる実務的なものだ。

どこに置くかを決める、という視点

FalkorDBは、ナレッジグラフの話題で名前が挙がる他のOSSとは担当領域が違う。テキストからノードと辺を作る仕事はせず、作られたグラフを保持して探索させることに集中している。疎行列と線形代数という内部表現、17本のコマンド、3種のインデックス、そして1インスタンスに複数グラフというマルチテナント構造が、その担当領域を支える具体的な中身だ。

一方で、SSPLv1というライセンス、Redis 7.4以上という前提、v4.20.0で外れたBoltサポートは、導入前に必ず確認しておきたい条件になる。「速いグラフDB」という一行だけで判断せず、この記事で挙げた項目を自分の構成に当てはめて確かめるのが確実だ。

参照ソース

・FalkorDB/FalkorDB — GitHub（README・src/module.c・src/commands/index_operations.c・.gitmodules・Cargo.toml・LICENSE.txt。2026-08-03 JST 参照）
・FalkorDB Releases — v4.20.0 / v4.20.1（Boltサポート削除を含む変更点。PR #2170 は2026-07-08マージ）
・FalkorDB/GraphRAG-SDK — GitHub（Apache-2.0。GraphRAG用途の公式SDK）
・FalkorDB 公式ドキュメント（クライアント一覧・コマンドリファレンス）
・SuiteSparse:GraphBLAS（deps/GraphBLAS として同梱。同梱ChangeLogの先頭は10.4.0 / 2026-07-31）