向量資料庫選型完整指南：Pinecone、pgvector、Weaviate、Qdrant、Milvus 五大平台決策框架與報價區間

「我用 Pinecone 跑了八個月，月帳單從 200 美元變 1,800 美元。沒人告訴我向量庫的計費方式有多不一樣。」

這是一位台灣 SaaS 創辦人在某技術社群分享的親身經歷。他做的是企業知識庫 RAG 系統，初期用量不大，Pinecone Serverless 感覺很划算。但隨著文件量突破 100 萬向量、查詢頻率飆升，帳單以指數曲線成長——而他意識到問題時，已埋好的資料管線和程式碼全都深度綁定 Pinecone API。要換庫，工程師得重寫超過三分之一的後端邏輯。

這不是個案。向量資料庫的選型決策，在 RAG 系統上線半年到一年後才開始真正「燒錢」。Gartner 2026 年的研究指出，超過 70% 的企業生成式 AI 方案需要結構化的檢索流程來降低幻覺和合規風險，向量資料庫已從實驗性技術升格為 AI 基礎設施的核心。整個向量資料庫市場在 2025-2026 年間成長 377%，估值從 2025 年的 28 億美元預計在 2028 年達到 85 億美元。

選對了，你的 RAG 系統可以低成本、高效能地支撐幾百萬到幾千萬筆向量。選錯了，返工成本輕則幾十萬、重則上百萬，還沒算上系統停擺的機會成本。這篇文章的目的，就是給老闆和 PM 一份可以直接上桌的決策框架——五個維度、五家平台、三種場景，讀完你就知道該用哪一家。

RAG 已是 AI 標配，但向量資料庫不是一個選法

什麼是向量資料庫？簡單說，它是用來儲存「語意向量（embedding）」的專用資料庫。傳統資料庫找資料靠完全匹配或關鍵字搜尋；向量資料庫靠「相似度搜尋」——把你的問句轉成向量，找到最接近的文件段落，再把這些段落塞給 LLM 當上下文。這就是 RAG（Retrieval-Augmented Generation）的核心機制。

RAG 的採用速度遠比大多數人預期的快。公開數據顯示，Gartner 預估到 2026 年將有超過 30% 的企業採用向量資料庫來豐富基礎模型的業務知識。光這個數字，就能感受到這個選型決策的份量。

問題在於，這個市場在短短兩年內從「幾乎沒有人用」暴增到「每家 AI 新創都在用」，各家平台的定位、架構、收費方式差異極大。Pinecone 主打雲端全託管；pgvector 是掛在 PostgreSQL 上的擴充套件；Weaviate 強調 GraphQL + 混合搜尋；Qdrant 以 Rust 打造、效能第一可自架；Milvus 瞄準 CNCF 雲原生超大規模場景。它們其實是針對不同規模和場景設計的不同工具，彼此之間並非互相競爭的相似產品。

五個維度讓你看懂平台之間的本質差異

在進入個別平台介紹之前，先建立評估框架。以下五個維度是採購決策中最關鍵的，每一個都會直接影響你的系統成本、維運負擔和未來擴充彈性。

QPS（Queries Per Second）代表系統在尖峰時每秒能處理多少查詢。Index 類型決定搜尋精度和記憶體用量。託管方案省維運、自架方案省錢。計費模式的差異往往是最大的隱藏地雷——Pinecone 的讀寫單位計費在大查詢量時費用暴增；pgvector 則幾乎沒有額外費用。

QPS 和 Index 類型：效能的基礎

HNSW（Hierarchical Navigable Small World）是目前最主流的向量索引算法，在精度和速度之間取得最好平衡。Qdrant 官方公開的 2026 年基準測試數據顯示，Qdrant 的 p99 查詢延遲可達 30ms，是主流方案中表現最穩定的。pgvector 在 v0.9 後加入 sparse vector 支援與 IVFFlat 改進，在 1M 向量規模下配合 HNSW，可以追平甚至超越專門的向量資料庫。Milvus 的分散式架構支援 DiskANN（基於 SSD 的索引），讓 10 億向量級別的查詢成為可能——但這個規模對大多數中小企業沒有意義。

託管 vs 自架：維運成本的天平

全雲端託管（Pinecone、Weaviate SaaS）的好處是零維運負擔，工程師不需要管叢集、備份、升級。代價是計費彈性低——流量一旦上去，費用跟著上去，而你沒有任何調控手段。自架方案（pgvector、Qdrant Docker、Milvus K8s）的維運成本是實際的工程師時間，通常每個月半到一天的工時，但計算資源費用可以控制在雲端 VM 成本範圍內，對用量大的場景有顯著優勢。

五家平台深度解析：各自的強項與地雷

Pinecone：最成熟的雲端全託管方案

Pinecone 是目前市場上知名度最高的向量資料庫。2024 年推出的 Serverless 模式讓入門門檻大幅降低——無需預先分配資源，按實際用量計費。10 萬向量的月費大約 3-8 美元，非常適合快速驗證。Standard 方案的儲存費用是 0.33 美元/GB/月，讀取單位 16 美元/百萬 RU，寫入單位 4 美元/百萬 WU。

問題出在規模化。1M 向量（1,536 維 float32）約 6.14GB 未壓縮，Pinecone 壓縮後約 1-1.5GB，儲存費月約 3.6-5.4 美元；但如果你的 RAG 系統每天有 10 萬次查詢，讀取費用會額外增加 40-80 美元，加上 Standard 方案 50 美元月費底價，實際帳單動輒 100 美元以上。到了 1,000 萬向量、百萬級查詢，Pinecone 的月費可以輕鬆超過 1,500 美元。

Pinecone 的另一個問題是 vendor lock-in。它使用專有 API 和 SDK，沒有開放標準相容性，一旦資料和程式碼深度耦合，遷移成本極高。適合場景：快速上線的 MVP、預算允許且不想管維運的新創、查詢量穩定不爆炸的中小型 RAG。

pgvector：直接掛 PostgreSQL，零額外維運成本

pgvector 最大的優勢是：你的 PostgreSQL 已經是向量資料庫了，什麼都不用換。v0.9 版本（2026 年初）加入稀疏向量支援、改進 IVFFlat，並帶來大幅速度提升。Supabase、AWS RDS、Neon 都原生支援 pgvector，幾乎不需要架設新服務。

在 1M 向量規模以下，pgvector + HNSW 的查詢延遲可以做到 30-50ms (p99)，已足夠覆蓋大多數 RAG 和語意搜尋場景。計費方面，如果你已經跑 PostgreSQL，pgvector 等同「免費升級」，唯一的成本是多占的記憶體和存儲。Supabase Pro 方案 25 美元/月已包含 pgvector，10 萬向量幾乎無感。

限制在哪？PostgreSQL 本質上是單機垂直擴展，1,000 萬向量以上開始出現效能瓶頸，而且 SQL 的連線池限制讓高並發 QPS 場景不如專用向量庫。此外，pgvector 不支援原生混合搜尋（dense + sparse 組合），需要額外整合 BM25 全文搜尋。適合場景：資料規模 100 萬以下、已有 PostgreSQL 基礎建設、工程資源有限的中小企業 RAG 或知識庫。

Weaviate：GraphQL + 混合搜尋的整合方案

Weaviate 最大的特點是原生混合搜尋——把 dense vector（語意）和 BM25 keyword（關鍵字）兩條搜尋結果用 RRF（Reciprocal Rank Fusion）算法融合，對需要精準語意 + 關鍵字雙重過濾的場景有明顯優勢。GraphQL API 讓前端工程師上手門檻低，也方便做複雜的 schema 設計和 data modeling。

Weaviate Cloud Serverless 的計費按物件數（每百萬物件約 25 美元/月）+ 查詢量，10 萬向量月費約 5-15 美元，1M 向量約 25-50 美元。自架版本完全開源，可以 Docker Compose 一鍵起服務。企業版有 RBAC、多租戶、備份等功能。適合場景：需要混合搜尋的推薦系統、客服 FAQ bot、文件搜尋，特別是對語意 + 關鍵字雙重精度有要求的場景。

Qdrant：Rust 打造的效能王，自架首選

Qdrant 是目前在公開基準測試中延遲最低的向量資料庫。官方發布的 2026 年測試數據顯示 p50 延遲 4ms、p99 30-40ms，Rust 底層實作帶來的效能優勢在高 QPS 場景格外明顯。Apache 2.0 授權開源，自架完全免費，Docker 起服務不到五分鐘。

Qdrant Cloud 的計費相對透明：1GB RAM 叢集約 25 美元/月，可支援約 100 萬個 1,536 維向量（搭配量化壓縮）。自架在 AWS EC2 或 GCP VM 上，4GB RAM 的機器可以撐 300-500 萬向量，費用跟著 VM 成本走，通常比同規模的 Pinecone 便宜 60-80%。Qdrant 也支援向量量化（scalar quantization、binary quantization），可大幅降低記憶體用量。適合場景：對效能敏感的即時推薦系統、高 QPS 場景、預算有限但技術能力足夠自架的團隊。

Milvus：CNCF 認證的超大規模方案

Milvus 是 CNCF（Cloud Native Computing Foundation）收錄的向量資料庫，架構本身針對超大規模設計——10 億向量以上的場景。計算與儲存分離架構，支援 Kubernetes 彈性擴縮，適合有完整 DevOps 和雲原生基礎建設的大型企業。Zilliz Cloud 是 Milvus 的全託管商業版，按 Compute Unit（CU）計費，月費從約 65 美元起。

對中小企業而言，Milvus 的複雜性通常是過度設計（over-engineering）。K8s 部署和維運需要專職 DevOps，這個門檻對多數台灣中小企業不現實。Milvus 的正確使用場景是：企業內部搜尋引擎（文件量超千萬）、大型電商的向量推薦系統、需要多租戶隔離的 SaaS 平台。

三種典型場景的選型建議

理解了各平台的特性之後，來看三種最常見的實際場景。這三種場景覆蓋了台灣中小企業 AI 系統採購的大多數情況：

有一個判斷維度很多人忽略：你的向量查詢，是 dense-only 還是需要 dense + sparse 混合？如果是企業知識庫或客服 FAQ，文件裡常有專有名詞、產品型號、縮寫——這些用純語意搜尋效果很差，必須加 keyword 搜尋。這種情況 Weaviate 的原生混合搜尋會比 pgvector 好很多。

月成本試算：三個規模、五家平台的真實報價對比

很多老闆在問「到底要花多少錢？」以下是三個規模的估算，基於各平台 2026 年 5 月的公開定價。實際費用因查詢頻率、向量維度、資料壓縮率而有所不同，此為中等查詢量（每天約 10 萬次查詢）的估算值。

一個真實的台灣案例可以說明這件事：某 B2B SaaS 公司把企業知識庫從 Pinecone Standard 遷移到 Qdrant 自架（EC2 c5.xlarge），500 萬向量規模，每月費用從 USD 600 降到 USD 180（含 EC2 + 儲存），節省 70%。代價是工程師花了兩週重寫整合層。他們在第三個月就回本。但前提是他們有 DevOps 能力——沒有的話，這兩週就可能是無底洞。

各平台的地雷與避坑場景

每個平台都有它最不適合的場景。以下是實際踩坑後整理的「不要用這個」清單：

五維度決策框架：從需求到選型的完整路徑

把前面的分析整合成一個可以實際操作的決策框架。你只需要回答五個問題，就能縮小選項到 1-2 家：

五個評估維度的快速自測：

• 資料規模：現在多少、未來兩年預估多少？（決定是否需要分散式架構）
• QPS 需求：每秒查詢量峰值是多少？（決定是否需要 Qdrant/Milvus 的效能優化）
• 搜尋類型：純向量語意搜尋，還是需要 keyword + 向量混合？（決定是否選 Weaviate）
• DevOps 能力：有沒有人能維護自架服務？（決定自架 vs 全託管）
• 合規需求：資料能不能出境？是否需要本地部署？（直接排除無自架選項的平台）

如果你的業務場景是企業內部知識庫 RAG，可以參考我們整理的

企業內部知識庫 RAG 90 天落地路線圖，裡面有從需求訪談到上線的完整步驟，以及向量資料庫整合的關鍵決策點。

生態系與 Vendor Lock-in：採購前必看的長期成本

短期的月費只是冰山一角。更難量化、但實際上更貴的是「換庫成本」——當你想換一家向量資料庫時，需要：重寫資料載入管線、重寫查詢邏輯、重新測試效能基準、遷移所有已建好的向量索引（重新 embedding 如果維度不同的話）。

Lock-in 風險評估：Pinecone 使用專有 REST/gRPC API，切換成本最高；pgvector 是 SQL 標準擴充，幾乎無 lock-in；Qdrant 和 Weaviate 都有 REST API + 多語言 SDK，且 client 庫之間有一定互換性；Milvus 有 PyMilvus SDK 且相容 Zilliz，生態相對封閉但開源。

建議在初期設計時就用 abstraction layer 把向量資料庫操作封裝成統一介面。如果你的 RAG 系統用 LangChain 或 LlamaIndex 搭建，這兩個框架都已原生支援 Pinecone / pgvector / Weaviate / Qdrant / Milvus 的 Vector Store 抽象層，未來切換只需要改幾行設定。更多關於 AI Agent 框架的選型，可以參考

AI Agent 框架選型指南（LangGraph / CrewAI / AutoGen）。

還有一個面向常被忽略：Graph 資料庫 vs 向量資料庫。如果你的知識庫有強關聯性的實體（例如組織架構、產品相依性、法規引用關係），純向量搜尋可能不夠——需要配合圖資料庫做 Graph RAG。可以參考

Neo4j 圖資料庫介紹：什麼時候該用 Graph Database？了解混合架構的設計思路。

從選型到上線：中小企業的三步實作路徑

選定平台只是開始。以下是把向量資料庫整合進 RAG 系統的實際步驟，適合技術主管用來規劃工程時程：

第一步：POC 驗證（1-2 週）

拿 1,000-10,000 筆真實業務文件做測試。用 OpenAI `text-embedding-3-small` 或 `text-embedding-3-large` 生成向量，分別試跑候選平台，測量：查詢延遲（p50 / p95 / p99）、搜尋精度（Recall@10）、上手難度。這一步不要省，它會幫你避開「選錯後 3 個月才發現」的悲劇。

第二步：技術架構確認（1 週）

確認向量資料庫與現有技術棧的整合方式：ORM 還是直接 SDK 呼叫？是否需要自建 abstraction layer？Embedding model 的輸出維度（1,536 / 3,072 / 768）有沒有對應的索引設定？Chunking 策略（固定長度 / 語意分段 / 父子結構）有沒有 schema 配合？關於 AI Pipeline 的整合細節，可以進一步參考

LangGraph Stateful Graph 與多 Agent 管線指南。

第三步：生產環境配置與監控（2-3 週）

在生產環境，向量資料庫的監控往往被忽略。你至少需要追蹤：查詢延遲分佈、每日向量數成長、索引碎片化程度（自架方案）、月費用趨勢（Cloud 方案）。Qdrant 自架版原生支援 Prometheus metrics；Pinecone 和 Weaviate SaaS 都有儀表板可以看用量。如果有 AI 觀測的需求，AI Agent 可觀測性的完整架構可以參考

AI Agent Observability 完整指南。

向量資料庫選對了，RAG 才能真正省錢又省力

回到開頭那位創辦人的故事。他後來怎麼了？他花了三週把系統遷移到 Qdrant 自架，重寫了向量存取層，月費從 1,800 美元降到 280 美元（EC2 c5.2xlarge + EBS 儲存）。損失的是三週工程師時間，換來的是每年超過 18,000 美元的成本節省，以及不再被平台計費模式綁架的安心感。

這篇文章的五維度框架告訴你一個核心原則：向量資料庫選型是技術決策，也是財務決策。10 萬向量的 MVP 和 1,000 萬向量的生產系統，需要截然不同的方案。pgvector 不是「次等選項」——對很多中小企業場景，它是最聰明的選擇。Pinecone 不是「萬用標準答案」——它的高價背後是便利性溢價，在意成本就得算清楚。

如果你正在規劃企業知識庫 RAG、AI 客服系統、或語意搜尋的架構，歡迎聯繫恆遠數位行銷的 AI 系統諮詢，我們可以協助你根據業務規模和技術能力做出最適合的向量資料庫選型，以及完整的 RAG 架構設計。

預約 AI 系統架構諮詢，30 分鐘釐清你的向量資料庫選型問題。