LatticeDB：一個內嵌的單檔案圖形資料庫，支援向量與全文搜尋

LatticeDB 是一個內嵌式、單檔案的屬性圖形資料庫，專為單一機器上的關係密集型工作負載而設計。它將圖形遍歷、HNSW 向量相似性搜尋以及 BM25 全文搜尋整合至單一查詢引擎中，無需為語意、文字與關係型資料分別使用不同的資料庫。

圖形、向量與文字的統一查詢層

LatticeDB 讓開發者能以單一查詢語言，根據關係、語意與文字來查詢資料。這種整合對於 Graph RAG 與代理記憶體系統特別有用，因為查詢可能需要尋找語意匹配、遍歷至相關實體，並依特定文字進行過濾。

Cypher 查詢語言支援

LatticeDB 實作了 Cypher 查詢語言的子集，支援關鍵操作，包括：

遍歷：MATCH、WHERE、RETURN 和可變長度路徑（例如 *1..3）。
修改：CREATE、DELETE、SET、REMOVE 和 MERGE。
搜尋運算子：<=> 運算子用於向量距離，@@ 運算子用於全文搜尋。
資料處理：WITH、UNWIND 和聚合運算，如 count、sum、avg、min、max 和 collect。

整合的搜尋功能

向量搜尋：使用分層可導航的小世界（HNSW）近似最近鄰搜尋，支援可設定的 M 與 ef 參數。支援內建的雜湊嵌入，並提供 HTTP 用戶端以連接 Ollama 與 OpenAI。
全文搜尋：採用 BM25 排名的反向索引，支援詞彙化、詞幹提取與可設定 Levenshtein 距離的模糊搜尋。

性能基準

LatticeDB 使用 Zig 語言撰寫，並針對低延遲的本地操作進行優化。在 Apple M1（單執行緒）上進行的基準測試顯示以下性能特徵：

核心操作延遲

操作	延遲	吞吐量
節點查找	0.13 µs	7.9M 操作/秒
節點建立	0.65 µs	1.5M 操作/秒
邊遍歷	9 µs	111K 操作/秒
全文搜尋（100 筆文件）	19 µs	53K 操作/秒
10-NN 向量搜尋（100 萬向量）	0.83 ms	1.2K 操作/秒

向量搜尋擴展性

在 100 萬個向量（128 維度的餘弦向量）規模下，LatticeDB 取得平均延遲 0.83 ms，且 100% 的 recall@10。搜尋延遲呈現次線性擴展（O(log N））。

圖形遍歷 vs. SQLite

LatticeDB 在圖形遍歷方面顯著優於 SQLite 的遞迴 CTE。在一個擁有 10 萬個節點與 50 萬條邊的社交網路圖中，兩跳遍歷在 LatticeDB 中僅需 38.7 µs，而 SQLite 則需 548.3 µs（加速 14 倍）。對於更深層的遍歷（深度 50），加速比達到 2,819 倍。

架構與運作模式

LatticeDB 遵循「本地優先」的哲學，類似於 SQLite 的運作簡潔性。

儲存：整個資料庫儲存在單一可攜式檔案中。
併發：採用內嵌的單寫入者模型。僅有一個程序擁有檔案，因此不適合多個應用程式同時寫入。
持久性：使用預寫日誌（WAL）進行災難恢復，並支援 ACID 交易，具備提交與還原功能。
事件串流：引擎內建持久化的命名串流與內建的圖形變更串流，與圖形寫入共用相同的交易/WAL 路徑。
綁定：雖然核心以 Zig 寫成，LatticeDB 提供官方的 Python、TypeScript/Node.js 與 Go 綁定。

使用情境分析

適合的使用情境

本地知識工具：需要圖形結構但不希望額外架設伺服器的應用程式。
代理記憶體與 RAG：結合語意搜尋與關係遍歷的流程。
連結的本地資料：管理引用圖、實體圖或個人筆記。
本地開發：在單一機器上原型設計 Neo4j 或 Weaviate 的應用。

不建議使用 LatticeDB 的情境

多寫入者需求：若多個應用程式需同時寫入同一資料庫，則需使用如 PostgreSQL 或 Neo4j 之類的客戶端-伺服器資料庫。
表格資料：若資料自然適合以行列形式儲存（例如銷售記錄），關係型資料庫仍更有效率。
分散式擴展：LatticeDB 限於單一機器，不支援跨叢集的分片或複製。
完整 Cypher 兼容性：目前尚未支援 OPTIONAL MATCH 或 CALL 程式。

社群見解

Hacker News 上的使用者指出此專案表現出色，且「何時不該使用」的文件實用性高。然而，也有報告指出基準結果存在一些差異。一位使用者（@adsharma）在 M4 Mac Mini 上測試時發現，雖然 LatticeDB 仍優於 SQLite 的遍歷表現，但加速比低於官方基準（例如，一跳遍歷僅有 2.8 倍加速，而非官方的 36 倍）。

其他社群討論也提到潛在的替代方案，並與其他新興的「本地優先」圖形工具（如 LadybugDB、SparrowDB 與 DuckPGQ）進行比較。