企業向量資料庫怎麼選?pgvector、Pinecone、Weaviate、Milvus 選型比較表

上週我們幫一家做法遵的金融科技團隊做技術盤點。他們的 RAG 系統跑得起來,但每次法規文件更新,重新索引要等四十分鐘,而且雲端向量庫的月帳單已經爬到六位數。工程師問我:「當初是不是選錯資料庫了?」

我看了一下,不是選錯,是選早了。他們在資料還只有兩萬筆的時候,就上了一套為億級規模設計的分散式向量庫。付了不需要付的營運複雜度。

這是我們在向量資料庫比較這件事上最常看到的誤區:大家拿著「未來要擴到十億筆」的假設,去選一個現在根本用不到的架構。所以這篇我不打算列規格表念一遍,而是用五個真正會影響上線的維度,把 pgvector、Pinecone、Weaviate、Milvus 攤開來講,最後給一個我們反覆驗證過的務實建議。

向量資料庫比較:五個真正決定成敗的維度

規格頁上有幾十個欄位,但實際上線後會咬你的,就這五個:資料規模、查詢延遲、營運成本、混合檢索能力、地端部署。其他都是細節。

資料規模決定你會不會過早複雜化。百萬筆以下,單機索引綽綽有餘;上到千萬、上億筆,才需要考慮分片與分散式協調。多數企業內部知識庫,合約、SOP、產品文件加起來,其實落在幾十萬到幾百萬筆之間。

查詢延遲要看的是 p95 尾延遲,不是平均值。Demo 時查一筆很快,並發上來之後長尾會炸開。這跟索引型態(HNSW vs IVF)和是否記憶體常駐關係很大。

營運成本包含兩塊,一塊是託管費用或機器成本,另一塊是工程師維運的時間。後者常被低估。多養一套獨立資料庫,就多一套備份、監控、升級、權限的活。

混合檢索是實務裡最容易被忽略的。純向量檢索在遇到專有名詞、料號、法條編號時會漏,得靠關鍵字 (BM25) 補。能不能在同一個查詢裡做 hybrid search,直接影響召回品質。

地端部署在金融、醫療、政府這幾個產業不是加分項,是門檻。資料不能出機房,再好的雲端服務也進不了場。

四款主流向量庫對照表

表看完,結論不是「哪個最強」,而是「你現在在哪個階段」。

為什麼多數團隊該先用 pgvector

我們給大部分客戶的第一建議,是先用 pgvector。原因很直接:企業的資料多半已經躺在 PostgreSQL 裡。用 pgvector,你不需要新增一套服務、不需要處理兩套資料的同步一致性、不需要多養一個維運對象。一句 CREATE EXTENSION vector; 就開始,向量和業務資料在同一次交易裡更新,不會有「文件刪了但向量還在」這種鬼打牆。

在數百萬筆這個量級,搭配 HNSW 索引,pgvector 的延遲對絕大多數企業應用完全夠用。需要混合檢索時,Postgres 本身的 tsvector 全文檢索就能補上關鍵字這條腿。地端?它本來就是開源,裝在你自己的機房沒有任何授權問題。

那什麼時候該搬家?當資料真的逼近上億筆、或每秒查詢數高到單機扛不住、或你需要 Pinecone 那種零維運的託管體驗來省下團隊時間——這時候再上 Milvus 或 Pinecone,是用真實痛點換複雜度,而不是為想像中的規模預先付費。

順帶提醒:向量庫的選擇很少是系統效能的瓶頸。分塊策略爛、embedding 模型跟你的中文語料不合、沒有重排 (reranking),換哪套資料庫都救不回來。先把這幾件事做對,再談要不要換庫。

我們自己在幫客戶導入 RAG 知識系統時,幾乎都是從 pgvector 起步,把檢索品質和上線採用先跑順、讓現場的人真的天天在用,等資料規模或並發真的撞到牆,再談遷移。Demo 上跑得動不算數,產線上有人用、答得準,才算數。這條線,我們踩過的雷比規格表誠實得多。