2026年9月4日 金曜日
AI時短ラボ
検証· 約12

「グラフ版SQLite」LatticeDBは1ファイルでベクトル検索・全文検索・グラフ探索を同じクエリ言語で扱う

OSSの組み込み型データベースLatticeDBは、プロパティグラフの走査・HNSVによるベクトル類似検索・BM25全文検索を、単一ファイル・単一クエリ言語の上で扱う。公式READMEが示す性能値はノード検索0.13マイクロ秒、100万ベクトルに対する検索0.83ミリ秒(recall 100%)。

「グラフ版SQLite」LatticeDBは1ファイルでベクトル検索・全文検索・グラフ探索を同じクエリ言語で扱う
執筆・編集:
目次

3行まとめ

  1. LatticeDBは、関係性の走査(グラフ)・意味的な類似検索(ベクトル)・キーワード検索(BM25全文検索)を同じデータセット・同じクエリ言語で扱える単一ファイルの組み込み型データベース。
  2. サーバーも設定ファイルも不要で、Python・TypeScript/Node.js・Go向けのバインディングが用意されている。
  3. READMEに掲載されている性能値はノード検索0.13マイクロ秒、100万ベクトルに対するベクトル検索0.83ミリ秒(recall 100%)。

3種類の検索を1つのクエリで書く

RAG(検索拡張生成)を自作しようとすると、たいていベクトルDB・全文検索エンジン・(必要なら)グラフDBを別々に立てて連携させることになる。LatticeDBが狙うのはその統合だ。READMEに掲載されているサンプルクエリは、Cypherに似た記法で「チャンクをベクトル距離で絞り込み、それが属する文書をたどり、さらにその著者をたどる」という一連の操作を1つのクエリで書けることを示している。

MATCH (chunk:Chunk)-[:PART_OF]->(doc:Document)-[:AUTHORED_BY]->(author:Person)
WHERE chunk.embedding <=> $query_vector < 0.3
  AND doc.content @@ "neural networks"
RETURN doc.title, chunk.text, author.name
ORDER BY chunk.embedding <=> $query_vector
LIMIT 10

<=>がベクトル距離、@@が全文検索のマッチ演算子として同じMATCH句の中に共存している。READMEはGraph RAGやエージェントのメモリ、ローカルの知識管理ツールを「このエンジンの上に構築できる例」として挙げつつ、それ自体をLatticeDBの定義とはしていない——あくまで汎用の組み込みDBであるという立て付けだ。

性能値と設計方針

README冒頭に太字で掲げられている数字は「ノード検索0.13マイクロ秒」「100万ベクトルに対するベクトル検索0.83ミリ秒(recall 100%)」の2つ。データベース全体が単一の可搬なファイルに収まり、サーバーも設定も不要、1プロセスが所有する前提のローカルファースト設計、単一ライターモデルでWAL(Write-Ahead Log)によって永続性を担保する、とREADMEは説明している。加えて、耐久性のある名前付きストリームと、グラフの変更を流すchangefeedが、グラフ書き込みと同じトランザクション/WALパスを共有する「イベントログ」機能も備える。

導入方法は言語ごとに用意

CLIはインストールスクリプト1行で導入できる。

curl -fsSL https://raw.githubusercontent.com/jeffhajewski/latticedb/main/dist/install.sh | bash

Pythonはpip install latticedb、TypeScript/Node.jsはnpm install @hajewski/latticedb、Goはcgo経由、そしてJava(JDK 21以上、JNI経由でGoバインディングと同じAPI構成)の合わせて4言語のバインディングが用意されている。配布されるパッケージはネイティブライブラリ(liblattice)を対応プラットフォーム向けに同梱する設計だとREADMEにある。本体はZigで書かれており、zig buildでソースからビルドできる。依存ライブラリはゼロ、とREADMEは明記している。

サンプルコードでは、埋め込みベクトルの生成にhash_embedというヘルパーが使われているが、これはREADMEが明確に「決定論的なプレースホルダーであり、意味的な埋め込みではない」と注記している関数だ。似たテキストが近いベクトルになるわけではないため、類似度の閾値は恣意的なものになり、類似検索が何もヒットしないこともある。実際の意味検索には別途、本物の埋め込みモデルを使う必要がある、という但し書きが明記されている。

開発者自身が挙げる「LatticeDBを選ぶべきでない場面」

READMEには「When to Use Something Else(別のツールを使うべき場面)」という節があり、開発者自身が次の5つのケースを挙げている。

  • 複数のアプリケーションが同時に同じDBへ書き込む必要がある場合:LatticeDBは単一ライターモデルの組み込みDBで、1プロセスがファイルを専有する。ネットワーク越しに多数のクライアントを接続したいならNeo4jやPostgreSQLを使うべき
  • データが本質的に表形式(テーブル型)の場合:売上記録やユーザーアカウントのような行と列に自然に収まるデータなら、SQLiteやPostgreSQLの方がシンプルで同程度に速い
  • 単一マシンを超えてスケールする必要がある場合:LatticeDBは1台のマシンの1ファイルにすべてを収める設計で、シャーディングや複数ノードでのレプリカ読み取りが必要ならNeo4jクラスタ・Dgraph・Neptuneのようなマネージドサービスを検討すべき
  • Cypher言語をフルに使う必要がある場合OPTIONAL MATCHCALLプロシージャなど、Cypherの一部機能はまだ実装されていない
  • 成熟したツール群・エコシステムが必要な場合:Neo4jのような可視化ツール・管理ダッシュボード・監視機能・各言語のドライバーは、新しく軽量なLatticeDBにはまだない

他のDBとの比較表──開発者自身が「測っていないもの」を切り分けている

READMEには、LatticeDBを他の既存DB・ライブラリと比較した表が複数掲載されている。ベクトル検索(100万件、10-NN)の比較を抜粋すると次の通り。

システム 10-NN検索レイテンシ 種別
LatticeDB 0.83ms(平均)、recall 100% 組み込み
FAISS HNSW(シングルスレッド) 0.5〜3ms ライブラリ
Weaviate 平均1.4ms、P99 3.1ms サーバー
Qdrant 約1〜2ms サーバー
Milvus + SQ8 P99 2.2ms サーバー
pgvector HNSW 約5ms(recall 99%時) 拡張機能
LanceDB 3〜5ms 組み込み
Chroma 平均4〜5ms 組み込み
Pinecone P2 約15ms(ネットワーク込み) クラウド

このほかグラフ探索(2ホップ、10万ノード)の比較表もあり、LatticeDBは39μs、SQLiteの再帰CTEは548μsと、こちらは開発者が「同一マシン・同一ハーネスで直接測定した」と明記する数値です。一方、比較対象のKuzu(19ms)やNeo4j(10ms、100万ノード規模)については、READMEが次のように自ら注記しています。

Only the SQLite rows are measured head to head on the same machine in the same harness. The Kuzu and Neo4j figures come from third-party posts on hardware and with methodology we do not control, so treat them as order-of-magnitude orientation rather than a benchmark result.

(SQLiteとの行だけが、同一マシン・同一ハーネスで直接測定されたものです。KuzuとNeo4jの数値は、私たちが管理していないハードウェアと手法によるサードパーティの記事から取ったものなので、ベンチマーク結果としてではなく、桁数の目安として扱ってください)

つまり開発者自身が「自分たちで測った数値」と「他所の記事から引用した数値」を明確に線引きしている点は、この記事にとって好材料でした。「ノード検索0.13マイクロ秒」「ベクトル検索0.83ミリ秒」というコア性能値についても、READMEには計測条件が明記されています——Apple M1・シングルスレッド・自動スケールするバッファプール(コア操作のベンチマーク)、128次元コサインベクトル・M=16・ef_construction=200・ef_search=64・k=10(ベクトル検索ベンチマーク)という条件です。

個人プロジェクトである可能性が高い、それ以上の裏取りはしていない

本記事はGitHubリポジトリのREADME・LICENSE・Javaバインディングのドキュメントを2026年8月にcurlで取得した内容にもとづく。LICENSEファイルの著作権表記は「Copyright (c) 2025 Jeff Hajewski」という個人名義で、企業名は見当たらず、個人プロジェクトである可能性が高いと考えられますが、これだけで企業の関与が完全にないと断定はできません。この記事執筆時点でのGitHubスター数は583でした。実際にpipやnpmでインストールし、100万件規模のベクトルを投入して自分の手元で数値を再現する検証は行っていません。Apple M1という計測環境が分かった一方で、CPUコア数やメモリ容量、データセットの具体的な内容(実データかランダム生成データか)まではREADME本文から確認できていません。

グラフ・ベクトル・全文検索を1エンジンに統合する設計は未紹介

Zenn・Qiitaともに言及はゼロだった。ベクトルDBやグラフDBそれぞれの比較記事は日本語圏にも存在するが、両方と全文検索を1ファイルの組み込みDBで統合するというアプローチは、まだ紹介されていない。

関連記事

シェア: ポスト はてブ

出典・参照資料

AIニュースの解説を動画でも

YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。

コメント

まだコメントはありません。最初のコメントを書いてみませんか?

AIについて聞きたいことはありますか?

質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。

質問箱を見る →

新しい記事をメールで受け取る

AIの新しい発表を、出典付きで整理して届けます。

関連記事