建立 2026-09-15 更新 2026-09-15

pgvector

pgvector 是 PostgreSQL 擴充：多一個 vector 型別、幾種距離運算子，以及 HNSW／IVFFlat 索引。向量跟訂單、使用者、權限放在同一套 SQL 裡，能 JOIN、能交易、能備份，這是它相對「獨立向量庫」最大的理由。

影片見 pgvector 影音。

什麼時候選它

• 系統已經在用 Postgres（含 Supabase、RDS、Cloud SQL、Neon 等有支援的託管）。
• 查詢必須混著關聯條件：WHERE tenant_id = ... ORDER BY embedding <=> ...。
• 資料量在單機 Postgres 能健康運作的範圍（常見是百萬級以內，視維度與記憶體而定）。

需要獨立擴展向量層、或召回／延遲有嚴格 SLO 時，再評估 Qdrant、Milvus、Pinecone。

核心語法

啟用擴充後，欄位維度必須與 embedding 模型一致。

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id          bigserial PRIMARY KEY,
  content     text,
  tenant_id   text,
  embedding   vector(384)
);

INSERT INTO documents (content, tenant_id, embedding)
VALUES ('退貨請於七日內提出申請。', 'acme', '[0.1, 0.2, 0.3]');

-- cosine 距離：越小越像。1 - 距離 ≈ 相似度
SELECT content, embedding <=> '[0.1, 0.2, 0.3]' AS distance
FROM documents
WHERE tenant_id = 'acme'
ORDER BY embedding <=> '[0.1, 0.2, 0.3]'
LIMIT 5;

運算子：

沒建 ANN 索引時是精確搜尋（掃過符合 WHERE 的列再算距離），結果最準，資料多了才需要索引。

索引怎麼選

CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops);

• HNSW：多數情況的預設。可在空表上建，查詢快、記憶體較多。
• IVFFlat：建得快、較省記憶體，但要先有資料做 lists，召回通常不如 HNSW。

運算子類別要跟查詢運算子一致（cosine 用 vector_cosine_ops）。建完近似索引後，結果可能與精確搜尋略有不同，這是預期行為。

應用層若走 PostgREST（例如 Supabase JS），距離運算子不能直接寫在 client，習慣上包成 SQL function 再用 rpc() 呼叫，官方語意搜尋文件有完整範例。

官方學習資源