2026 向量資料庫怎麼選:pgvector vs Pinecone vs Qdrant vs Weaviate
那個悄悄決定整個 AI 架構的向量資料庫選擇
如果你在 2026 年做任何跟 LLM 相關的東西,你就是在跟向量打交道。RAG、語意搜尋、推薦系統、代理人記憶、甚至風控,這些系統的表現都取決於你怎麼儲存和查詢 embedding。你選的向量資料庫不是抽象的基礎設施決策——它會決定你的延遲、你的每月帳單、你在 metadata 上做篩選的能力,以及六個月後要遷移時有多痛。
但多數團隊選資料庫的方式,跟 2023 年時沒什麼兩樣:看到哪篇部落客文章就用哪個。市場已經不一樣了。Pinecone 不再是唯一一個值得認真考慮的託管方案;pgvector 已經穩穩跨入生產級;Qdrant 成為在乎 Rust 等級吞吐量的團隊最愛;Weaviate 則加倍押注在混合搜尋和多模態檢索上。在 2026 年選錯的代價比兩年前更高,因為工作負載變大了,而「還可以」跟「很棒」之間的差距也拉開了。
這是一份決策指南,不是排行榜。我們會走過每個選項真正適合的場景、會在什麼時候默默毀掉你一週,以及那些行銷頁面傾向略過的權衡。
2026 年改變了什麼(以及為什麼你舊的假設已經過時)
自從上一波向量資料庫文章以來,有三件事發生了變化。
第一,embedding 維度暴增。從 1536 跳到 3072 維(像是 text-embedding-3-large 和許多開源權重模型),儲存量不是 2 倍變化——因為 HNSW 圖的開銷,實際接近 4 倍。2024 年感覺游刃有餘的索引,現在需要 3 到 4 倍的記憶體。有團隊在 2024 年初用 768 維向量對 pgvector 做基準測試、結論是太慢,等到 3072 維重測時會吃一驚——失敗模式看起來一樣(查詢慢),原因完全不同(維度,不是資料庫)。
第二,metadata 篩選不再是 nice-to-have。生產環境的 RAG 幾乎都會把語意查詢跟硬性篩選結合起來:租戶範圍、文件類型、新舊、地理區域、語言。你的向量資料庫怎麼處理這個篩選——在 HNSW 圖內、作為後置篩選、還是走另一條索引路徑——現在是真實世界延遲的單一最大預測因子。沒有篩選時 15 毫秒的查詢,加上高選擇性篩選可能膨脹到 200 毫秒,資料庫能不能優雅處理這個差距,就是產品能不能上線的差別。
第三,「直接用 Postgres」變成一個站得住腳的答案。pgvector 0.7+ 加上 pgvectorscale 擴充,補上了當初把人們從 Postgres 推走的絕大多數差距。對為數不少的團隊來說,2026 年的正解就是他們本來就在跑的資料庫。早期那些反對意見——規模大時太慢、篩選不好用、索引維護痛苦——在 pgvector 一個版本一個版本中被各個擊破,這個團隊現在在多數團隊真正會有的工作負載下,已經可以跟專門打造的系統正面競爭。
四個競爭者,誠實地評估
pgvector——通常對的那個無聊答案
pgvector 是 PostgreSQL 的擴充功能。向量跟你的關聯式資料住在同一個地方,交易性保證涵蓋它們,備份也涵蓋它們,你的應用程式不用在兩個系統之間協調,就能對 metadata 進行篩選。
誠實的優點:如果你已經在跑 Postgres,這是阻力最低的路徑。最關鍵的特性是查詢——向量相似度加上 SQL 述詞,一句話搞定,搭配 row-level security、join、ACID 交易,全都照你預期的方式運作。想在另一個獨立的向量服務重現這個,你得在應用層自己做 join,或把篩選條件塞進 metadata,但那會繞過 HNSW 圖,把效能壓垮。
誠實的缺點:它是單節點的擴充功能,沒有水平分分的故事。在單一實例上,向量數量超過大約 200 萬時,索引建立時間開始超過 20 分鐘,VACUUM 操作也開始跟線上查詢搶資源。超過 500 萬向量時,你得考慮唯讀副本、分區,或者直接換工具。另外,pgvector 的 metadata 篩選是對候選集做後置篩選,不是在 HNSW 圖內,所以高選擇性的篩選(拒絕 95% 以上候選的那種)會很慢。
主觀看法:對大多數在建第一個或第二個 RAG 系統的團隊,pgvector 是正確的預設。之後要遷移很煩,但不是世界末日。你省下來的維運複雜度,可以用來投資在檢索品質上——那才是真正會拉動結果的地方。
Pinecone——上手快,規模大時貴
Pinecone 是完全託管、專門打造的向量資料庫。你透過 API 送向量進去,它幫你存,你查詢就好。沒有基礎設施、沒有分片決策、沒有升級維護窗口。Serverless 定價代表你不用為閒置容量付錢。
誠實的優點:零維運負擔。Pinecone 可以處理數十億等級的向量,團隊完全不用想。託管的 pod 部署上,p95 延遲在規模化時仍維持在 30 毫秒以下。如果你的團隊很小、時間很貴,而且有比調索引更重要的事要煩,Pinecone 確實有它的價值。
誠實的缺點:Pinecone 的價格是按儲存的維度數計費,不是按用量。5000 萬個 3072 維向量,跟 5000 萬個 768 維向量,對話是完全不同的等級。還有,它對索引可調控性的能力有限——你沒辦法自己控制準確度跟效能的權衡。系統幫你做這些決定,沒問題的時候很 OK,但需要的時候就很煩。混合搜尋(向量相似度加上 BM25 關鍵字)也不是一等公民,最後你會在應用層自己拼出來。
主觀看法:當你不想碰向量基礎設施、也願意為那個方便付費時,Pinecone 是對的答案。當你對成本敏感、需要精細控制索引、或是真的要大規模做混合搜尋時,它是錯的答案。
Qdrant——高效能的專家
Qdrant 是用 Rust 寫的開源向量資料庫,篩選能力是一等公民,對需要可預測低延遲的生產部署有很強的故事。Qdrant Cloud 是託管版;自架的話,基本上「一個 docker run」就能上線。
誠實的優點:吞吐量。Qdrant 在 100 萬向量、768 維的基準下,能穩定跑到 800+ QPS,p95 延遲在個位數毫秒。篩選是在 HNSW 圖內做的,不是後置篩選,所以高選擇性的篩選不會把候選集撐爆。Rust 程式碼基底小到真的可以從頭讀完。Qdrant 是那些「比起生態系熟悉度,更在乎延遲預算」的團隊會選的資料庫。
誠實的缺點:生態系。Qdrant 跟更廣的資料工具鏈整合度,不如 pgvector(它就是 Postgres)或 Pinecone(每個主流框架都預先接好)。Qdrant Cloud 以外的維運成熟度是真的,但需要會 Rust 或至少熟 Docker 的工程師。社群比 Postgres 或 Pinecone 小,凌晨三點踩到邊角案例時,Stack Overflow 上的答案會少一些。
主觀看法:如果你的工作負載偏篩選、對延遲敏感、又沒被 Postgres 綁住,Qdrant 是最多團隊忽略的那個生產級答案。推薦系統、即時個人化、任何把向量相似度跟結構化述詞結合的場景,都特別適合。
Weaviate——混合搜尋跟多模態,但有學習曲線
Weaviate 是開源的向量資料庫,主打混合搜尋(單一查詢裡結合 BM25 跟向量)和內建的向量化模組。它的 schema 模型比其他三者更複雜,既是優點也是成本。
誠實的優點:混合搜尋是一等公民。如果你的檢索問題真的需要語意相似度加上關鍵字匹配——法律文件、程式碼搜尋、技術支援內容——Weaviate 有最成熟的實作。多模態檢索(文字、影像等)也比 pgvector 或 Pinecone 整合得更好,GraphQL API 在做複雜查詢時是真的好用。
誠實的缺點:schema 模型跟 SDK 歷史帶來的認知負擔,除非你真的用到那些功能,否則划不來。對只想「存向量、查相似度」的團隊來說,Weaviate 是超出需求的機器。實際用過的團隊對它的維運心得參半——資料庫本身會動,但學習曲線是真的,從 Weaviate 遷出也不是小事。
主觀看法:Weaviate 在混合搜尋跟多模態勝出。如果你兩者都不需要,你在為用不到的功能付維運稅。
真正重要的決策矩陣
| 場景 | 最佳選擇 | 原因 |
|---|---|---|
| 100 萬向量以下,已經用 Postgres,1-5 人團隊 | pgvector | 阻力最低;SQL + 向量同個地方;只需維運一個資料庫 |
| 100-500 萬向量,流量可預期,想零維運 | Pinecone Serverless | 沒有基礎設施;p95 維持 30 毫秒以下;規模不大時成本可預期 |
| 500 萬以上向量,延遲敏感,篩選吃重 | Qdrant Cloud 或自架 Qdrant | 在 HNSW 圖內篩選;Rust 等級吞吐量;可預期的 p95 |
| 混合關鍵字+向量搜尋是核心需求 | Weaviate | 一等公民的 BM25 + 向量融合;成熟的混合實作 |
| 多模態檢索(文字+圖+音) | Weaviate 或 Pinecone(搭配多模態索引) | 兩者都有原生支援;Weaviate 在生產上比較成熟 |
| 嚴格的資料落地 / 只能地端 | pgvector 或自架 Qdrant | 兩者都跑在你的 VPC;資料不出你的基礎設施 |
| 規模化時對成本敏感(5000 萬以上向量) | pgvector 配唯讀副本,或自架 Qdrant | 託管服務在這個規模變貴;維運權重值得換 |
什麼時候這是好的選擇——什麼時候不是
單看資料庫本身的優缺點來選,是錯誤的。對的選擇取決於三件事:你的團隊、你的資料、你的規模軌跡。
pgvector 適合的場景:團隊已經在運維 Postgres、向量數量在幾十萬到幾百萬之間、檢索模式是向量相似度搭配結構化述詞。不適合:單一實例上超過 500 萬向量、需要全球 20 毫秒以下的 p95、或是要在高 QPS 下做即時個人化。
Pinecone 適合的場景:團隊小、時間貴、有比向量基礎設施更重要的問題要解。不適合:成本是主要約束、需要精細控制索引、或是要大規模做混合搜尋。
Qdrant 適合的場景:工作負載偏篩選、延遲敏感、又沒被 Postgres 綁住。不適合:團隊完全沒有多餘維運能量、需要大量生態系整合、向量數量少到維運複雜度不划算。
Weaviate 適合的場景:混合搜尋或多模態檢索是核心需求、有工程能量吸收 schema 模型的複雜度。不適合:只需要基本的向量相似度——你在為用不到的功能付維運稅。
生產環境常見的錯誤
- 跳過索引參數調校。HNSW 參數(m、ef_construction、ef_search)對延遲跟召回率有 2 到 5 倍的影響。預設值保守是有原因的,但如果你從來不量測召回率,等於在盲飛。
- 把高選擇性篩選當成後置篩選。如果你的篩選拒絕 99% 候選,向量搜尋就得掃完整個 HNSW 圖才能找到足夠的鄰居。要嘛重組篩選、要嘛反正規化資料、要嘛選一個在圖內做篩選的資料庫(Qdrant、最近的 Weaviate)。
- 選 embedding 維度時沒算成本。3072 維的 embedding 儲存量約是 768 維的 4 倍。如果你不需要那個召回率,你就是在為你沒在量測的準確度付錢。
- 把向量搜尋當成瓶頸。在大多數 RAG 系統,瓶頸是檢索品質,不是檢索速度。當你的切塊策略有問題時,花一週調 HNSW 參數是搞錯優先順序。
- 忘記備份、PITR、災難復原。pgvector 繼承 Postgres 工具鏈;Pinecone 和 Qdrant Cloud 幫你處理;自架 Qdrant 跟 Weaviate 得自己來。在你有 5000 萬向量又沒備份之前,先規劃好。
- 忽略 metadata schema 設計。你跟向量一起存的 metadata 決定了你能跑哪些篩選。如果你把文件類型編碼成自由文字欄位,接下來幾個月你會在清理資料。
- 太早遷移。多數團隊在專案生命週期內只換一次向量資料庫。選那個符合你 18 個月後預期規模的,不是你今天規模的。但也別過度設計——100 萬向量放在 Pinecone 沒問題;到 1000 萬再遷也來得及。
實用的決策檢查清單
在承諾一個向量資料庫之前,跑一遍這份清單。
- 估算 18 個月後的向量數量。如果你在 100 萬以下,幾乎任何選擇都行。如果你會跨過 500 萬,選擇就重要了。
- 辨識你的篩選模式。如果你的向量搜尋搭配結構化篩選,優先選擇在 HNSW 圖內篩選的資料庫。
- 決定維運責任歸屬。如果你的團隊完全沒有多餘能量處理新基礎設施,託管服務預設就勝出。如果有資料庫工程師,自架就變得有競爭力。
- 檢查生態系適配性。你用 LangChain、LlamaIndex 還是自幹?主流框架都支援四個選項,但整合品質有差。
- 務實編列預算。Pinecone 和 Weaviate Cloud 在 10 萬向量時看起來很便宜,在 5000 萬時就貴了。pgvector 和自架 Qdrant 在 10 萬時看起來貴(因為算人力),在 5000 萬時就便宜了。
- 用你的真實工作負載做原型。合成基準會誤導人。拿一個有代表性的實際資料切片,在承諾之前量測召回率、延遲跟成本。
- 規劃遷移路徑。就算現在不遷移,也要知道遷移的成本。從 pgvector 匯出是小事;從 Pinecone 匯出得用他們的工具。
現在值得做的事 vs. 仍然過度炒作的事
現在值得做的:把向量資料庫的選擇當成一個真正的工程決策,而不是預設值。選那個符合你規模跟篩選模式的資料庫。用真實工作負載量測召回率,不要用合成資料。在你還沒有 5000 萬向量跟清理專案之前,先投資 metadata schema 設計。在承諾一個供應商關係之前,花一週用你的實際資料做原型。
仍然過度炒作的:「託管向量資料庫永遠比較便宜」這件事。小規模時,沒錯,便宜。1000 萬以上向量加上穩定流量時,算式就翻轉了。還有過度炒作的:追逐最新的「向量資料庫」新創。這份指南裡的四個選項,是 2026 年四個真正站得住腳的競爭者;新資料庫的長尾大多是行銷,不是工程。另外過度炒作的:「維度愈多、embedding 愈好」這個假設。Matryoshka 風格的訓練跟二進位量化,讓低維度 embedding 變得出奇地有競爭力,許多生產系統在為它們沒在量測的準確度付錢。
還有一件事值得大聲講出來:我看過太多團隊在這個決策上過度設計,卻在檢索品質上投資不足。切塊策略、embedding 模型選擇、混合搜尋、重排序,這些對生產環境 RAG 勝出的貢獻,比底下的向量資料庫更大。選一個合理的預設,把系統推出門,等真的有規模問題再回頭看這題。一個很棒的向量資料庫配上普通的檢索品質,永遠打不過一個普通的向量資料庫配上很棒的檢索品質。
用 18 個月的時間尺度看這件事
2026 年的向量資料庫市場比兩年前成熟,但還沒定下來。有三件事值得關注。
第一,embedding 模型的整合。當少數幾個大型 embedding 模型佔據主導(開源權重模型也跟專有模型縮小差距),跟向量一起存的 metadata 會比向量本身更重要。當初把 schema 設計成能捕捉文件類型、來源、新舊、來源脈絡的團隊,會比那些把向量當成不透明 blob 處理的團隊,處於強勢得多的位置。
第二,磁碟式向量索引的崛起。多數生產向量資料庫還是會把整個 HNSW 圖放在 RAM 裡,這是規模化時最大的成本驅動因子。磁碟式跟混合記憶體/磁碟索引(DiskANN 風格的做法、pgvectorscale 的 StreamingDiskANN)已經好到可以在生產環境部署,並且會大幅改變成本算式。如果你在為 5000 萬以上向量規劃基礎設施,12 個月後再回來看一次是值得的。
第三,整合的故事。當向量搜尋變成通用資料庫(就像 Postgres、MongoDB、Elasticsearch、甚至 SQLite)的一個特性,而不是一個獨立產品,「我需要一個獨立的向量資料庫嗎」這個問題會變得更容易回答。在 2026 年,這個問題還是微妙的。到了 2027 年,對多數工作負載,答案可能就是「不需要,你已經在用的資料庫做得就很好」。
這些都不代表你今天做的決定不重要。它代表你今天做的決定,應該要是那個在接下來 18 個月符合你規模跟團隊的決定,並且清楚知道如果市場變動,遷移路徑看起來是怎樣。選那個無聊的答案,把系統推出門,等資料告訴你是時候再回來檢視。
常見問題
pgvector 在 2026 年達到生產級了嗎?
是的,在合適大小的 Postgres 實例上,500 萬以下向量大多沒問題。超過這個量級,你得考慮分區、唯讀副本,或者換工具。
Pinecone 什麼時候會比自架貴?
大約在你跨過 500-1000 萬向量加上穩定查詢流量時,或是你的 embedding 維度超過 1536 時。精確的交叉點取決於你的流量模式跟團隊的完全負載成本。
之後可以換向量資料庫嗎?
可以,但很煩。向量格式是可攜的;metadata、索引參數、篩選模式,還有依賴它們的應用程式碼,都不是。規劃專案生命週期內會有一次遷移。
我根本需要向量資料庫嗎?還是可以用檔案搜尋就好?
10 萬份文件以下,記憶體暴力搜尋就夠了。超過這個量級,你會想要真正的索引。在 100 萬向量之前,這個複雜度就划得來了。
那新的向量資料庫呢(Lance、Vexilla 之類)?
它們很有意思,但還沒累積出這份指南裡四個選項的那種維運紀錄。對 2026 年的生產系統來說,押注在有口碑的選項上是比較安全的賭注。
簡短結論
用 Postgres 就預設 pgvector。不想煩就選 Pinecone。工作負載偏篩選又對延遲敏感,選 Qdrant。混合搜尋是核心需求,選 Weaviate。在你實際推出產品之前,別在這個決策上過度鑽研,把精力放在檢索品質上。