什麼是 vector database?你真的需要嗎?

Vector database 是專門儲存與搜尋高維向量的系統 — 也就是 AI 模型產出的 embedding。它是任何 RAG、語意搜尋、推薦系統的儲存層。「你需要 vector DB」這句話有道理,但專門 vector DB 跟「Postgres 裝 pgvector」之間的取捨,比行銷文案複雜得多。

Vector DB 在做什麼

核心工作:給定幾百萬個向量,快速找出最接近某個查詢向量的 K 個。

暴力法是 O(n) — 把查詢跟每個存好的向量比一次。1 萬筆 OK(毫秒),100 萬筆很痛苦(秒級),1 億筆完全不可行。

Vector DB 用 approximate nearest neighbor(ANN) 索引 — 通常是 HNSW(Hierarchical Navigable Small World)或 IVF(Inverted File Index) — 達到次線性搜尋。犧牲一點點精度(1-5% 的機率錯過真正最近的鄰居)換大幅加速。對語意搜尋來說,這個取捨幾乎永遠值得。

搜尋之外,現代 vector DB 還提供:

Metadata 過濾 — 「找相似向量,且 category = 'docs' 而且 updated_at > 2025-01-01」
Hybrid 搜尋 — 把向量相似度跟關鍵字(BM25)分數結合
Multi-tenancy — 依使用者/團隊/workspace 隔離向量
接 reranker — top-K 丟給 reranker 模型重排
持久化與備份 — 持久儲存、複本

2026 年的選項

大致分三群:

Postgres extension:

pgvector — 預設選項。Open source,任何 Postgres 都能裝(包括 Supabase、Neon、RDS)。約 1000 萬筆內舒適。跟 app 資料同一個 DB,免分開維運。
pgvectorscale — Timescale 在 pgvector 之上的擴充,加 StreamingDiskANN 索引,可到十億級。

專門 managed:

Pinecone — 雲端 vector DB 元老,成熟、可擴到十億,$70/mo 起。
Weaviate Cloud — 開源核心 + managed,schema 模組化。
Qdrant Cloud — Rust 寫的、快、免費額度大方。
Milvus / Zilliz Cloud — 大規模、複雜些。

嵌入式 / 輕量:

Chroma — Python 嵌入式函式庫,開發友善。Prototype 好,production 比較弱。
DuckDB / SQLite 向量擴充 — 嵌入式、單檔、適合離線或 edge。
LanceDB — 欄式向量儲存,掃描快,熱度上升中。

怎麼真的挑

大多數人適用的決策樹:

**剛起步、向量 < 1000 萬、已經用 Postgres?**用 pgvector。一個 DB、ship 快、大多數 app 不會超出。
**要 5000 萬以上向量、嚴格延遲 SLA、零維運預算?**用 Pinecone 或 Qdrant Cloud。
**全部自架、要開源?**Qdrant 或 Weaviate。
**Edge、mobile、local-first?**SQLite 向量擴充或 LanceDB。
**在 Python 裡 prototype?**Chroma 摩擦最少。

Over-engineering 陷阱:第一次做 RAG 的創辦人挑 Pinecone 因為它「AI-native」,後來發現自己的 app 用同一個 Postgres + pgvector 還更簡單。多數人第二個月就後悔。

真實效能數字

設定一下期待(2026 世代硬體):

Supabase Pro 上 pgvector + HNSW,10 萬筆 1,536 維向量:p95 查詢延遲 5-20ms,月 $25(Supabase 方案,不是 vector DB 本身的錢)。
同硬體下 1000 萬筆:p95 30-100ms。
Pinecone serverless 1000 萬筆:p95 20-50ms,月 $70-200(看用量)。
$20/mo VPS 自架 Qdrant:10 萬筆 → 2-10ms。

規律:pgvector 對 ~95% 的 app 已經夠快,差距只在規模或嚴格 SLA 才出現。

Metadata 問題

常見坑:embed 完文件、放進 vector DB,才發現要按 tenant_id、created_at、category 過濾。有些 vector DB 處理得優雅,有些不。

pgvector 繼承 Postgres 完整 SQL:任何 WHERE 都能用。Metadata 故事最強。
Pinecone、Qdrant、Weaviate:各有 metadata filter 語法,常常微微受限。
Chroma:簡單 metadata 過濾,基本案例 OK。

如果你的檢索需要結構化過濾、不只是「top-K 向量 + 沒 constraint」,pgvector 通常贏。

什麼時候根本不用 vector DB

**文件 < 1,000 份。**完全跳過 vector store。請求時即時 embed + 記憶體暴力比、或全部塞進 LLM context window。
**查詢主要是完全比對。**用 Postgres FTS(全文搜尋)或 BM25,向量是大砲打蚊子。
**資料能塞進 RAM、永遠很小。**Python dict + numpy.argmax 有時候就是正解。
**還沒撞到「檢索品質」的牆。**如果瓶頸是切塊不對或 embedding 模型錯,換更花俏的 DB 也救不了。

遷移成本

實務考量:換 vector DB 煩但不致命。通常不必重 embed — 把向量 + metadata 匯出,匯入新 DB。大多數團隊會在規模逼到時做一次。先用 pgvector 起步、有需要再遷,不要預先優化。