Qdrant Vector Database — A Field Guide

Qdrant is a vector database written in Rust, and that choice shows up in practice more than the marketing copy suggests: no GC pauses under load, a small memory footprint per vector, and a single static binary you can run anywhere from a laptop to a Kubernetes pod. What makes it worth a dedicated post rather than a footnote next to pgvector is its indexing and filtering model — it was built from the start to do similarity search and structured filtering together, not similarity search with filtering bolted on afterward.

Collections, points, and payloads

Qdrant's data model has three pieces. A collection is roughly a table — it fixes the vector dimensionality and distance metric (cosine, dot product, or Euclidean) up front. A point is a row: an ID, one or more named vectors, and a JSON payload — arbitrary structured metadata like {"tenant_id": 42, "status": "published", "price": 19.99}. The payload isn't just stored for retrieval; it's indexed and queryable, which is the part that matters.

Filterable HNSW: the actual engineering problem

Approximate nearest neighbor search at scale almost always means HNSW (Hierarchical Navigable Small World graphs) — a layered graph structure where search starts at a sparse top layer and descends into denser layers, letting you find near-neighbors in the full dataset without scanning every vector. That part is not unique to Qdrant; most vector databases use some HNSW variant.

The harder problem is combining that with a metadata filter — "find the 10 nearest vectors to this query, but only among points where tenant_id = 42 and status = 'published'." Naively, you either filter before search (which breaks the graph traversal because your candidate set becomes ANN-unfriendly) or filter after search (which means you might get zero results back if the top-k nearest neighbors all fail the filter). Qdrant's approach threads the filter into the graph traversal itself, using payload indexes to prune the search as it walks the HNSW graph rather than as a separate pass. In practice this means a filtered query on a well-indexed payload field stays close to unfiltered-query latency instead of degrading linearly with filter selectivity.

A collection with filtered search, in practice

This is the shape of almost every real Qdrant integration I've built: create a collection with a payload index, upsert points with vectors plus metadata, then query with both a vector and a filter in the same call.

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="docs",
    vectors_config=VectorParams(size=768, distance=Distance.COSINE),
)
client.create_payload_index(
    collection_name="docs", field_name="tenant_id", field_schema="keyword"
)

client.upsert(
    collection_name="docs",
    points=[
        PointStruct(id=1, vector=embed("Acumatica GI export limits"),
                    payload={"tenant_id": "acme", "status": "published"}),
        PointStruct(id=2, vector=embed("Laravel queue retry strategy"),
                    payload={"tenant_id": "acme", "status": "draft"}),
    ],
)

results = client.search(
    collection_name="docs",
    query_vector=embed("how do I export a generic inquiry"),
    query_filter=Filter(must=[
        FieldCondition(key="tenant_id", match=MatchValue(value="acme")),
        FieldCondition(key="status", match=MatchValue(value="published")),
    ]),
    limit=5,
)

Qdrant vs. pgvector vs. Pinecone

The honest comparison depends on what you already run. pgvector is a Postgres extension — if your data already lives in Postgres, adding an embedding vector(768) column and an IVFFlat or HNSW index is genuinely less operational surface than standing up a second database. For most RAG prototypes and even a lot of production systems under a few million vectors with simple metadata filters, pgvector is enough, and "enough" is underrated. You keep one backup strategy, one connection pool, one set of ops runbooks.

Where a dedicated vector store like Qdrant earns its keep is when filtering gets complex (many payload fields, nested conditions, geo filters) and needs to stay fast as you scale past what a Postgres index can comfortably handle, or when you need features Postgres doesn't have natively — sharding across nodes, quantization to shrink memory footprint, or multiple named vectors per point (e.g. a text embedding and an image embedding on the same document). Pinecone sits on the other side: fully managed, no ops at all, but you give up self-hosting, and its filtering model has historically been less expressive than Qdrant's. If data residency matters — which it often does for clients running ERPs with strict data-locality requirements — self-hosted Qdrant is the more comfortable answer than a managed US-hosted service.

Wrapping up

Qdrant's real contribution isn't "another HNSW implementation" — it's making metadata filtering a first-class part of the search itself instead of a pre- or post-processing step bolted onto ANN. That's the feature to evaluate it on. If you don't have complex filters or you're already in Postgres, pgvector will get you further than the hype suggests. If you do have multi-tenant data with real filter logic and you're scaling past what a single Postgres instance handles comfortably, Qdrant's design earns the extra moving part.