Why Switching from Chroma to Qdrant Hits a 1 Million‑Vector Performance Pitfall

TL;DR

Choosing a vector database is not about comparing feature lists; it is about fitting your scenario parameters (data volume, query complexity, operational constraints) into a decision framework.

Decision‑matrix overview

Personal project / quick prototype : Chroma – zero ops, pip‑install, lives in the same Python process.

Data < 1 000 000 vectors: both Chroma and Qdrant work, differences are negligible.

Data > 1 000 000 vectors: Qdrant – Chroma starts to struggle.

Complex filters (time + tags + status): Qdrant – filterable HNSW keeps recall high.

Very tight budget + massive data (TB‑scale): Chroma – S3 storage is ~250× cheaper than pure RAM.

Production / high‑availability needs: Qdrant – Raft consensus, horizontal sharding, auto‑repair.

Two runnable code snippets

Install the libraries:

pip install chromadb qdrant-client

Chroma – embedded mode

import chromadb
# No separate service – runs inside your Python process
client = chromadb.Client()
collection = client.create_collection(
    name="my_docs",
    metadata={"hnsw:space": "cosine"}
)
collection.add(
    documents=[
        "Python 的 asyncio 在 3.11 后性能提升明显",
        "Qdrant 用 Rust 写的，GIL 管不着它",
        "Chroma 默认用 HNSW 做索引"
    ],
    metadatas=[
        {"topic": "python", "year": 2024},
        {"topic": "vector-db", "year": 2025},
        {"topic": "chroma", "year": 2024}
    ],
    ids=["doc_1", "doc_2", "doc_3"]
)
results = collection.query(query_texts=["向量检索怎么加速？"], n_results=2)
for i, doc_id in enumerate(results["ids"][0]):
    doc = results["documents"][0][i]
    distance = results["distances"][0][i]
    print(f"[{doc_id}] {doc} (distance: {distance:.3f})")

Qdrant – independent service

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
import numpy as np
# Start Qdrant (docker or cloud) first
client = QdrantClient(host="localhost", port=6333)
client.create_collection(
    collection_name="my_docs",
    vectors_config=VectorParams(size=384, distance=Distance.COSINE)
)
client.upsert(
    collection_name="my_docs",
    points=[
        PointStruct(
            id=1,
            vector=np.random.rand(384).tolist(),
            payload={"topic": "python", "year": 2024, "text": "Python 的 asyncio 在 3.11 后性能提升明显"}
        ),
        PointStruct(
            id=2,
            vector=np.random.rand(384).tolist(),
            payload={"topic": "vector-db", "year": 2025, "text": "Qdrant 用 Rust 写的，GIL 管不着它"}
        ),
        PointStruct(
            id=3,
            vector=np.random.rand(384).tolist(),
            payload={"topic": "chroma", "year": 2024, "text": "Chroma 默认用 HNSW 做索引"}
        )
    ]
)
results = client.search(collection_name="my_docs", query_vector=np.random.rand(384).tolist(), limit=2)
for hit in results:
    print(f"[{hit.id}] {hit.payload['text']} (score: {hit.score:.3f})")

Chroma lives in your program’s process like an embedded SQLite; Qdrant runs in a separate office‑like service.

How the two engines work internally

Chroma starts a Rust Tokio runtime inside the Python process, pushes query plans as tiny “morsels” to multiple workers, and merges results in a bitmap layer. New vectors are searchable immediately because there is no separate indexing step.

The downside appears after roughly 1 000 000 vectors: the merge‑layer overhead grows and cross‑language communication becomes a bottleneck, causing latency to swing between 20 ms and 200 ms.

Qdrant runs as an independent process accessed via HTTP/gRPC. It stores data in segmented files, writes a WAL before applying changes, and isolates segment reads from writes. Filterable HNSW applies bitmap masks during graph traversal, so semantic search and complex filters execute together without hurting recall.

Performance boundaries

Chroma: benchmark shows latency rising from 50 ms to 800 ms when the index passes the 1 M‑vector threshold; the cause is Rust‑Python crossing overhead and memory‑bloat‑induced GC pauses.

Qdrant: remains stable up to 50 M vectors, delivering ~41 queries‑per‑second with 99 % recall, thanks to SIMD, segment isolation, and TurboQuant compression.

If you only have 5 × 10⁴ vectors, Qdrant’s extra container adds operational cost without noticeable benefit.

Filtering – the often‑overlooked killer

When you need to filter 500 000 documents by multiple tags and a date range, Chroma either searches first then filters (losing precision) or filters first then searches (severe slowdown). Qdrant’s filterable HNSW performs both steps in one pass, keeping speed and recall consistent.

The more complex your WHERE clause, the more you should consider Qdrant.

When things go wrong

A real‑world pitfall: running Chroma inside a Flask service caused the Python GIL to serialize vector distance calculations and HTTP responses, leading to high latency under load. Moving the vector store to an independent Qdrant service isolated the workload and eliminated the bottleneck.

How to decide

Answer four questions about your project:

Will the vector count exceed 1 M within a year?

Are filter conditions simple tags or complex multi‑field expressions?

Are you willing to maintain a separate service?

Is RAM cost a concern at large scale?

Apply the answers to the following rules:

Data < 1M & simple filter   → Chroma
Data < 1M & complex filter  → Qdrant
Data > 1M                  → Qdrant (almost mandatory)
Tight budget + huge data  → Chroma (S3 storage is far cheaper)
Agent / context management → Chroma (native support)

My current practice: start new projects with Chroma for rapid validation, then migrate to Qdrant once the data volume or query complexity reaches the documented thresholds. The code snippets above let you try both options on your own data today.