Qdrant vs Chroma vs pgvector：為自託管 RAG 挑選合適的向量資料庫

Qdrant vs Chroma vs pgvector：為自託管 RAG 挑選合適的向量資料庫

Qdrant vs Chroma vs pgvector 的選擇歸結為三種權衡：專為速度優化、原型開發的簡易性，或是留在 PostgreSQL 生態系內。每種方法都可行，關鍵在於哪種權衡最符合您的 RAG（檢索增強生成）流程需求。

快速總結：您該選擇哪個向量資料庫？

選擇 Qdrant，如果您需要具備進階過濾功能、多租戶支援的生產級向量搜尋，且不介意運行獨立的服務。

選擇 Chroma，如果您正在進行原型開發、希望零設定的本地開發環境，或需要在不到一小時內將想法轉化為可運作的 RAG 系統。

選擇 pgvector（搭配 pgvectorscale），如果您已經在使用 PostgreSQL，並希望在无需增加基礎設施的情況下實現向量搜尋，特別是現在 pgvectorscale 的 StreamingDiskANN 索引 已經縮小了效能差距。

如果您正在從頭建構 RAG 應用程式，本文其餘部分將幫助您選擇正確的基礎架構。

效能：每個資料庫的速度如何？

當文件數量超過幾千份時，效能就變得至關重要。這三個資料庫在此方面有著顯著差異。

Qdrant

Qdrant 從底層開始就是為向量搜尋而建構的。其 Rust 實作與客製化的 HNSW 索引能提供一致的低延遲，基準測試顯示即使在併發負載下，查詢延遲也約為 94 毫秒。它支援純量、二進位和乘積量化，以壓縮向量並加速搜尋，同時將召回率保持在 95% 以上。

Qdrant 的真正優勢在於過濾搜尋。不同於先尋找最近鄰居再進行過濾的資料庫，Qdrant 的可過濾 HNSW 會在圖形遍歷過程中尊重元數據約束。這意味著當您結合向量搜尋與如 category = "technical" 或 date > 2025-01-01 等過濾器時，不會損失召回率。

Chroma

Chroma 的 1.0 版本發布 將核心重寫為 Rust，與原始的 Python 實作相比，寫入和查詢速度提升了 3-5 倍。2025 年 8 月的後續更新增加了 base64 向量編碼，進一步提升了 70% 的吞吐量。

對於少於一百萬個向量的數據集，Chroma 確實非常快。它嵌入在您的 Python 程序中運行，沒有網路開銷，這使得本地迭代非常迅速。但它是一個單節點資料庫，沒有內建的分片或複製功能。

pgvector + pgvectorscale

這是黑馬選手。使用 HNSW 的標準 pgvector比順序掃描快 5,250 倍，而 pgvector 0.8.0 增加了迭代索引掃描，解決了早期版本中困擾使用者的過度過濾問題。

但真正的亮點是 pgvectorscale。Timescale 的這個擴充套件添加了受 Microsoft DiskANN 研究 啟發的 StreamingDiskANN 索引，將索引儲存在磁碟而非記憶體中。在對 5,000 萬個 Cohere 嵌入向量（768 維度）的基準測試中，pgvectorscale 達到了 99% 召回率下的 471 QPS。這比 Qdrant 在相同召回率下的 41 QPS 高出 11.4 倍的吞吐量，且 p95 延遲比 Pinecone 的儲存優化索引低 28 倍。

缺點？這些基準測試使用的是高規格 EC2 執行個體。實際效果取決於硬體配置。但趨勢很明確：PostgreSQL 不再是向量搜尋中「勉強夠用」的選項，它已經具備真正的競爭力。

結論：pgvector + pgvectorscale 在原始基準測試數據上獲勝。 Qdrant 在過濾搜尋效能上勝出。Chroma 對於原型開發足夠快，但並非為大規模擴展而設計。

設定與開發者體驗

從零開始到擁有向量搜尋需要多久時間？

Qdrant：Docker 與 Go

Qdrant 需要自己的容器：

docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant

然後透過 REST API 或官方 SDK（Python、Rust、Go、TypeScript）插入向量：

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

Qdrant 在 localhost:6333/dashboard 提供的儀表板是一個不錯的加分項，您可以瀏覽集合、執行查詢並視覺化檢查負載。從開發到生產的路徑非常清晰：您的本地 Docker 設定在生產伺服器或 Qdrant Cloud 上都能以相同方式運作。

Chroma：pip Install 即可完成

Chroma 在簡易性競賽中以巨大優勢勝出：

import chromadb

client = chromadb.Client()  # In-memory, zero config
collection = client.create_collection("documents")
collection.add(
    documents=["Your RAG document here"],
    ids=["doc1"]
)

無需 Docker。無需伺服器。如果您不提供向量，它甚至會自動處理嵌入生成。對於 RAG 原型，您可以從 pip install chromadb 開始，在不到 10 行程式碼內實現可運作的搜尋。

當您需要持久化儲存時，切換到 chromadb.PersistentClient(path="./chroma_data")。對於多程序或網路存取，Chroma 有伺服器模式，但在那時，您開始失去其簡易性的優勢。

pgvector：全程使用 SQL

如果您的技術堆疊中已經有 Postgres，pgvector 只需一行指令：

CREATE EXTENSION vector;

CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

一切皆為 SQL。您的嵌入向量與應用程式數據位於同一個交易中。沒有同步管道、沒有單獨的憑證、沒有額外的服務需要監控。如果您已經在生產環境中運行 PostgreSQL，這是最省力的途徑。

如果您使用 Timescale 的 Docker 映像 或支援它的託管 Postgres 供應商，在其基礎上添加 pgvectorscale 也很直接：

CREATE EXTENSION vectorscale;
CREATE INDEX ON documents USING diskann (embedding);

缺點？SQL 的人體工學設計不如 Qdrant 的負載過濾 DSL 或 Chroma 的 Pythonic API 那麼直觀。而且您需要管理自己的嵌入管道，pgvector 不會為您生成嵌入向量。

結論：Chroma 在最快速原型開發上獲勝。 如果您的技術堆疊中已有 Postgres，pgvector 獲勝。Qdrant 在開發者體驗與生產就緒之間取得了最佳平衡。

擴展與生產就緒性

原型開發是一回事。運行一個處理數百萬個向量且延遲一致的 RAG 流程則是另一回事。

Qdrant：為水平擴展而生

Qdrant 開箱即用支援水平分片。您可以將集合分散到多個節點，並配置複製因子以實現高可用性。其 2026 年路線圖包括讀寫分離和塊儲存整合，以實現更好的擴展。

多租戶是一級功能。您可以使用基於負載的過濾按租戶分割數據，而無需創建單獨的集合，這保持了資源使用效率。對於處理多用戶的 AI 代理記憶系統 來說，這是一個有意義的優勢。

運營層面相當穩固：內建備份、Prometheus 指標端點，以及基於 WAL 的崩潰恢復。Qdrant 專為在生產環境中自託管而設計。

Chroma：單節點上限

Chroma 誠實地面對其限制。它是一个專注於簡易性和本地開發的單節點資料庫。沒有內建的分片、複製或叢集功能。

Chroma Cloud 於 2026 年初作為無伺服器、分散式託管選項全面上市，因此您可以將水平擴展工作卸載到那裡，而不是自行運行。但自託管的開源故事主要仍是「一台伺服器，一個 Chroma 實例」。如果您的數據集適合單台機器（根據維度不同，最多幾百萬個向量），那沒問題。超過這個範圍，自託管 Chroma 就會遇到瓶頸，您必須在 Chroma Cloud 和遷移之間做出選擇。

pgvector：隨 Postgres 擴展

pgvector 繼承了 PostgreSQL 經久考驗的擴展故事。您擁有讀取複本、透過 PgBouncer 的連接池，以及邏輯複製。像 Neon 和其他類似的無伺服器 Postgres 平台 這樣的託管供應商讓垂直擴展幾乎毫不費力。

pgvectorscale 的 StreamingDiskANN 索引是擴展的關鍵解鎖點。因為它將索引儲存在磁碟（SSD）而非記憶體中，您可以處理 otherwise 需要昂貴高記憶體實例的數據集。在 5,000 萬個向量時，它已經可以與專為向量設計的資料庫競爭。

限制在於水平分片。PostgreSQL 不像 Qdrant 那樣原生支援分片。雖然存在 Citus 等解決方案，但會增加複雜性。對於大多數低於 1 億個向量的自託管 RAG 工作負載，使用 pgvectorscale 進行垂直擴展已足夠。

結論：Qdrant 在水平擴展和多租戶支援上獲勝。 pgvector 在利用現有 Postgres 基礎設施上獲勝。Chroma 並非為生產級擴展而設計。

自託管成本

這三者都是開源且免費運行的。真正的成本在於基礎設施和工程時間。

pgvector 具有結構性的成本優勢：如果您已經為 Postgres 付費，添加向量搜尋本質上是免費的，直到您需要專用資源為止。沒有額外的容器、沒有額外的監控、沒有額外的備份策略。

Qdrant 的資源使用效率以其功能集來說相當高效，但它是一個獨立的服務，您需要將運行和監控另一個基礎設施部分的運營開銷計算在內。

Chroma 在原型階段最便宜（零基礎設施），但如果您試圖將其擴展到單節點無法處理的范围，它會成為最昂貴的路徑。

關於在雲端平台上部署這些服務，Qdrant 和 pgvector 都有基於 Docker 的直接部署方式。Chroma 也可以，但您會失去其作為主要賣點的嵌入式簡易性。

結論：pgvector 在總擁有成本上獲勝。 它從您的技術堆疊中消除了一個完整的服務。Qdrant 的價格對於其提供的功能來說是合理的。Chroma 的成本效益僅在原型開發階段成立。

過濾與混合搜尋

RAG 不僅僅是「找到最近的向量」。您需要將相似度搜尋與元數據過濾器、日期範圍、存取控制，有時甚至是關鍵字匹配結合起來。

Qdrant：過濾之王

Qdrant 的負載過濾發生在 HNSW 遍歷期間，而不是之後。這是一個關鍵區別。後過濾可能會導致您的結果數量低於要求；預過濾保證您獲得符合約束的 k 個結果。

過濾 DSL 表達力強：

from qdrant_client.models import Filter, FieldCondition, MatchValue

results = client.search(
    collection_name="documents",
    query_vector=embedding,
    query_filter=Filter(
        must=[
            FieldCondition(key="category", match=MatchValue(value="engineering")),
            FieldCondition(key="year", range=Range(gte=2024)),
        ]
    ),
    limit=10,
)

Qdrant 還支援在同一查詢中使用稠密和稀疏向量進行原生混合搜尋，這對於結合語義理解與關鍵字精度非常有用。

Chroma：基本但可用

Chroma 支援帶有 where 子句的元數據過濾：

results = collection.query(
    query_embeddings=[embedding],
    where={"category": "engineering"},
    n_results=10,
)

這適用於簡單情況，但過濾發生在向量搜尋之後。使用限制性過濾器和小數據集時，您可能會得到比預期更少的結果。沒有稀疏向量支援或內建混合搜尋。

pgvector：SQL 是您的超級力量

pgvector 繼承了 SQL 用於過濾的全部威力：

SELECT content, embedding <=> $1 AS distance
FROM documents
WHERE category = 'engineering'
  AND created_at > '2024-01-01'
  AND content @@ to_tsquery('RAG & retrieval')
ORDER BY distance
LIMIT 10;

最後一行在單一查詢中結合了向量相似度與 PostgreSQL 內建的全文搜尋。不需要外部搜尋引擎。您可以聯接用戶表以進行存取控制、聚合結果、使用 CTE，任何 SQL 能做的事它都能做。

pgvector 0.8.0 的迭代掃描也有幫助。如果初始 HNSW 掃描沒有返回足夠的過濾結果，它會自動繼續搜尋，而不是返回部分集合。

結論：Qdrant 在大規模複雜元數據過濾上獲勝。 pgvector 在混合搜尋靈活性上獲勝（單一查詢中的 SQL + 全文 + 向量）。Chroma 的過濾僅適用於原型開發。

何時使用各項方案：決策框架

以下是決策樹版本：您的應用程式是否已經使用 Postgres？如果是，從 pgvector 開始，如果以後超出其能力範圍，您隨時可以遷移。如果否，您是在進行原型開發還是為生產環境建構？原型開發選 Chroma。生產環境選 Qdrant。

「從簡單開始，稍後遷移」的方法是有效的，因為這三者都支援標準嵌入格式。在它們之間移動向量是數據遷移，而不是架構重寫。

pgvectorscale 因素：為什麼 Postgres 正在趕上

值得深入探討這一點，因為它改變了許多團隊的計算方式。

在 pgvectorscale 出現之前，人們對 pgvector 的批評總是「它在少於一百萬個向量時運作良好，但無法擴展」。這是事實。HNSW 索引完全駐留在記憶體中，一旦您的數據集超過可用記憶體，效能就會急劇下降。

StreamingDiskANN 改變了局面。透過將圖形索引儲存在 SSD 而非記憶體中，pgvectorscale 能夠以 99% 召回率處理 5,000 萬個向量，達到 471 QPS。統計二元量化（SBQ）以最小的準確度損失壓縮向量，即使進行積極壓縮，召回率也僅從 98.6% 降至 96.5%。

實際影響：在 Postgres 上運行 RAG 流程的團隊不再需要計劃在「事情變得嚴重時」遷移到專用的向量資料庫。對於許多工作負載來說，pgvector + pgvectorscale 就是那個嚴肅的選項。

話雖如此，pgvectorscale 並非萬靈丹。它是 TigerData（前身為 Timescale）的擴充套件，因此您需要他們的 Docker 映像或捆綁它的供應商。2026 年的版本為 StreamingDiskANN 添加了基於標籤的過濾向量搜尋，靈感來自 Microsoft 的 Filtered DiskANN 研究，這縮小了 Qdrant 在過濾查詢方面長期以來的領先優勢。但如果您需要多租戶隔離或原生稀疏向量支援，Qdrant 仍然具有優勢。

Techsy 如何選擇向量資料庫

當我們為客戶建構 RAG 流程時，我們的評估過程如下：

1. 審計現有技術堆疊。 如果團隊已經運行 Postgres，pgvector 是預設起點。除非有明確理由，否則無需增加基礎設施複雜性。
2. 分析查詢模式。 具有高基數字段的重度元數據過濾？這傾向於選擇 Qdrant。簡單的語義搜尋？pgvector 或 Chroma 即可。
3. 估算擴展軌跡。 低於 500 萬個向量並保持不變？任何選項都可行。計劃達到 5,000 萬+？根據步驟 2 選擇 pgvectorscale 或 Qdrant。
4. 檢查團隊的運營能力。 兩人新創公司不應管理 Qdrant 叢集。帶有 pgvector 的託管 Postgres 供應商通常是正確的選擇。

我們使用這三者都建構過生產級 RAG 系統。誠實的答案是，資料庫的選擇不如您的分塊策略、嵌入模型和檢索管道設計重要。如果您花在辯論 Qdrant vs pgvector 上的時間多於測試不同分塊大小的時間，您就是在優化錯誤的事情。

需要幫助設計 RAG 流程嗎？向量儲存選擇和檢索設計是我們 AI 整合服務 的一部分。聯繫我們，我們將幫助您選擇正確的基礎並圍繞它建構層級。

常見問題

pgvector 對於生產級 RAG 足夠好嗎？

是的，特別是搭配 pgvectorscale。StreamingDiskANN 索引在基準測試中以擊敗專用向量資料庫的吞吐量水平，處理 5,000 萬+ 向量並達到 99% 召回率。如果您已經運行 Postgres，很少有需要為 RAG 添加單獨向量資料庫的理由。

Chroma 能擴展到數百萬個向量嗎？

Chroma 可以在具有足夠記憶體的單節點上處理幾百萬個向量，但它沒有內建的水平擴展功能。對於超出單台機器容量的數據集，您需要遷移到 Qdrant、pgvector 或託管服務。

Qdrant 支援帶有關鍵字的混合搜尋嗎？

是的。Qdrant 在同一集合中支援稠密和稀疏向量。您可以運行結合語義相似度（稠密）與關鍵字匹配（稀疏）的混合查詢，並控制它們之間的權重。

每個資料庫需要多少記憶體？

這取決於向量數量和維度。粗略指導：1536 維度的 100 萬個向量在 Qdrant 或帶有 HNSW 的 pgvector 中大約需要 6GB。由於 Python 開銷，Chroma 使用略多一點。pgvectorscale 的 DiskANN 索引透過將索引儲存在 SSD 上，大幅降低了記憶體需求。

我以後可以在這些資料庫之間遷移嗎？

是的。這三者都使用標準浮點數組，因此向量是可移植的。您需要重新創建索引並調整查詢層，但這是數據遷移，而不是重寫。大多數遷移工具（如 Qdrant 的 官方遷移工具）簡化了這一過程。

哪一個與 LangChain 和 LlamaIndex 配合最好？

這三者都有與 LangChain 和 LlamaIndex 的官方整合。Chroma 經常是教程中的預設選項，使其成為入門最順暢的選擇。Qdrant 和 pgvector 的整合對於生產使用同樣成熟。查看我們關於 最佳 RAG 工具 的指南，以更廣泛地了解生態系統。

我應該使用 pgvector 還是 pgvectorscale？

兩者都用。pgvector 提供核心的 vector 類型和 HNSW 索引。pgvectorscale 在其之上添加 StreamingDiskANN 以在大規模下獲得更好的效能。它們是互補的擴充套件，而非替代方案。

Qdrant 自託管免費嗎？

在 Apache 2.0 授權下完全免費。Qdrant Cloud 是付費的託管選項，從免費的 1GB 層級開始。對於自託管，您只需支付計算基礎設施費用。

那 Milvus 或 Weaviate 呢？

兩者都是可靠的替代方案。Milvus 在非常大規模（十億+ 向量）且具有 GPU 加速方面更強。Weaviate 擁有不錯的內建向量化管道。但對於低於 1 億個向量的自託管 RAG，Qdrant、Chroma 和 pgvector 以較低的運營複雜性覆蓋了絕大多數用例。

pgvector 能在生產環境中處理併發 RAG 查詢嗎？

是的。PostgreSQL 專為併發工作負載而設計。pgvector 繼承了連接池（PgBouncer）、讀取複本和 MVCC 併發控制。對於高吞吐量 RAG，將 pgvector 與連接池配對並調整 shared_buffers 和 effective_cache_size。

最終結論

整體而言： 對於大多數自託管 RAG 流程，pgvector + pgvectorscale 是務實的選擇。它足夠快，可擴展到數千萬個向量，並保持您的技術堆疊簡單。您已經熟悉 SQL。您的團隊已經管理 Postgres。少一個服務意味著凌晨 2 點少一件可能出錯的事情。

如果您需要進階過濾搜尋、多租戶支援，或者正在建構一個以向量搜尋為核心功能（而非輔助功能）的產品，Qdrant 是正確的投資。它是最功能齊全的開源向量資料庫，是有原因的。

Chroma 贏得了其作為原型開發工具的地位。使用它來驗證您的 RAG 方法，測試不同的分塊策略，並迭代檢索品質。當您準備好進入生產環境時，遷移到其他兩個中適合您技術堆疊的任何一個。

最好的建議？停止辯論，開始建構。如果您有 Postgres 就選 pgvector，如果沒有就選 Qdrant，並讓您的 RAG 流程運作起來。您隨時可以更換向量儲存，嵌入模型、分塊策略和檢索邏輯要重要得多。

來源

• Qdrant 基準測試
• Chroma 1.0 發布：速度快 4 倍
• pgvectorscale：PostgreSQL 的 StreamingDiskANN
• pgvector 現在比 Pinecone 快且成本低 75%
• pgvector 0.8.0：迭代索引掃描
• Qdrant 定價