在資料管理領域中,嵌入式圖資料庫佔據著特殊利基。它們提供圖形查詢的強大功能,卻無需運行獨立的資料庫伺服器,使其成為本地開發和應用程式的理想選擇。KuzuDB 曾是這個領域中最具前景的開源專案之一,以其速度和可擴展性聞名。截至 2025 年 10 月,該專案的 GitHub 儲存庫已被正式封存,這消息在開發者社群中引起了震驚與失望的漣漪。
開發工作的突然終止
當訪客發現 KuzuDB 的儲存庫被標記為已封存時,消息便傳開了。開發團隊留下一則訊息表示:「Kuzu 正在開發新東西!我們將不再積極支援 KuzuDB。」這個大約在 2025 年 10 月 10 日左右發布的公告,標誌著一個歷經數年、擁有長期且穩定提交紀錄的專案突然中止。此舉的突然性讓許多使用者,包括貢獻者及下游專案(如 GitLab 最近宣布的知識圖譜功能),對他們現有實現方案的未來感到憂心。時機點尤其令人好奇,因為據報導,在專案被擱置前不久,開發團隊還正積極開發雲端和企業解決方案,並與潛在客戶接洽。
一位使用者道出了許多人的心聲,他表示:「說來奇怪,就在我發現這個強大的嵌入式圖資料庫的同一天,那個『已封存』的橫幅也出現了。」
社群反應與尋找替代方案
開發者社群的反應混合了失望與務實的問題解決。許多人已習慣依賴 KuzuDB 的 Python 函式庫進行本地實驗,並認為它「超級方便」。這些使用者的當務之急是尋找合適的替代品。討論很快轉向了替代解決方案。一個被提及的潛在候選是 DuckPGQ,它是熱門嵌入式分析資料庫 DuckDB 的一個圖形查詢擴充功能。最近一篇學術論文展示了其對抗成熟圖資料庫(如 Neo4j)的競爭性能。其他建議還包括 CozoDB、Dgraph、SurrealDB 和 FalkorDB,不過後者被指出並非嵌入式解決方案。這種爭相尋找替代方案的狀況,凸顯了在開源生態系統中,快速、嵌入式圖資料庫相對稀有的現狀。
提及的 KuzuDB 替代方案:
- DuckPGQ: 一個用於 DuckDB 的圖查詢擴充功能,在基準測試中展現出具競爭力的效能。
- CozoDB: 一個名稱相似的嵌入式圖資料庫,但據報導開發速度已經放緩。
- Dgraph: 一個使用 Go 語言編寫的原生 GraphQL 資料庫。
- SurrealDB: 一個支援多種資料模型的多合一資料庫。
- FalkorDB: 一個圖資料庫,但要注意的是它並非嵌入式解決方案。
技術遺產與未盡的疑慮
儘管已被封存,KuzuDB 仍留下了顯著的技術遺產。它被設計為一個進程內資料庫,意味著它無需外部伺服器,直接嵌入在應用程式中運行,並將資料直接儲存在磁碟上。其架構利用列式儲存和向量化處理來提升效能。它採用了屬性圖資料模型和圖資料庫界流行的標準查詢語言 Cypher。然而,一位社群成員提出了一個關鍵的技術疑慮:其磁碟儲存格式從未穩定下來。使用近期版本的使用者必須在每個新版本發布時不斷匯出和重新匯入他們的資料,因為舊版本的檔案會變得無法讀取。雖然隨著開發終止,這已不再是問題,但它對於任何潛在的分支或未來專案而言,都是一個關於穩定儲存層重要性的警示。
KuzuDB 的主要特色(已封存):
- 架構: 嵌入式、行程內運作(無需伺服器)。
- 儲存: 磁碟儲存,從基於目錄的方式過渡到單一檔案。
- 效能: 採用列式儲存和向量化處理。
- 查詢語言: 針對屬性圖資料模型使用 Cypher。
未來之路與信任問題
KuzuDB 的封存引發了關於開源專案可持續性與使用者信任的更廣泛問題。一些評論者對於採用同一團隊未來的任何專案表示懷疑,認為放棄一個專案會為所有基於它進行建構的人帶來不確定性。這種觀點與另一種看法形成對比,即開源專案,特別是那些使用寬鬆許可證(如 MIT)的專案,並不欠使用者任何東西。開發者承諾「正在開發新東西」暗示了方向的轉變,但在缺乏細節的情況下,社群只能猜測。此事件強調了科技界常見的困境:一邊是創新、敏捷專案的吸引力,另一邊則是 PostgreSQL 或 SQLite 等老牌廠商所提供的長期穩定性。
KuzuDB 的故事在快節奏的開源軟體世界中屢見不鮮——一個有前途的專案抓住了開發者的想像力,卻突然被中止。它的離去在嵌入式圖資料庫的領域中留下了一個空缺。儘管社群已經開始積極探索和建構替代方案,但此事件提醒我們,無論是開發者還是使用者,都必須在創新與可靠性之間取得微妙的平衡。
參考資料:嵌入式、可擴展、極速圖資料庫
