我們六個圖資料庫中的兩個在完全相同的負載下掛掉。這其實是件好事
外帶作業：公平地對 CognoDB 與其他幾個圖資料庫進行基準測試。公平規則很直接——每個資料庫都只能使用相同的極小資源上限：0.5 vCPU、256MB RAM，沒有例外。
說起來容易。有兩個平台沒能撐過去。
Memgraph 在匯入過程中不斷被 Linux OOM reaper 殺掉。一開始猜是缺少索引。錯了，檢查過、修正了，還是掛掉。第二次猜是儲存模式。Memgraph 的分析模式會跳過預寫日誌以加速匯入，聽起來很有希望。結果它也不支援基準測試所需的唯一性約束——你只能二選一，不能同時擁有。回到正常模式，乾淨地跑了一次，再跑一次確認。
又被殺掉了。設定正確的情況下兩次乾淨的失敗不是運氣不好。這是 Memgraph 的記憶體內交易引擎有個真正的記憶體底限，256MB 的機器無法通過。
ArangoDB 則是因為完全不同的原因失敗。它的文件深處提到：除非明確告訴它，否則它不會真的偵測 Docker 容器的記憶體限制。若放任不管，它會根據主機機器的 RAM 來調整內部快取，而不是容器的。設定了覆寫後，有進展，但還是掛了。
到了這個階段，誠實的選擇是：放寬上限直到所有東西都能塞進去（這會完全失去測試的意義），或者交付少於要求的資料庫數量。兩個都不對，所以專案中途加入了第五個平台——Kùzu，一個嵌入式圖資料庫，它直接在你自己的行程內執行，而不是作為獨立的伺服器。在你載入任何一列資料前，不會有閒置的常駐程式。
使用它時的峰值記憶體：1.94MB。在 256MB 中。而 Memgraph 和 ArangoDB 試圖存放相同資料時，就在這個數字上掛掉。
最終的實際結果比「本地端獲勝」更有趣。Kùzu 的「索引」查詢根本不是索引——它是一次完整掃描，設計上就不支援傳統索引。它還是比 AuraDB 真正的索引查詢快了大約 40 倍（4.7ms 對 196.7ms）。這不是更聰明的查詢引擎，而是直接測量出雲端資料庫的延遲有多少只是網路來回，而不是實際的工作量。
FalkorDB 和 Kùzu 的表現也沒有乾淨地分出高下。FalkorDB 贏了所有遍歷查詢，但在聚合上輸得很慘——在那個項目上比真正的雲端資料庫還慢。不同的引擎、不同的優勢，沒有單一贏家。
這些結果都沒有變成乾淨的五個綠勾勾表格，而這正是重點。如果第一次 Memgraph 嘗試就成功了，這些事情永遠不會浮上檯面。
完整方法論、每一次失敗、每一個數字：repo link。