Qdrant

Qdrant is an open source vector database for similarity search: instead of matching records with conditions, it finds them by geometric proximity in high dimensional space, so a search takes a query vector and returns the nearest points ordered by score.

At CyberElectro it runs as a Docker container and serves the vector search behind our retrieval features. Port 6333 carries the REST API and the web dashboard, port 6334 the gRPC API.

Collections, points and named vectors

A collection is a named set of points to search among, all with the same dimensionality and compared by a single metric. Named vectors give each embedding of a point its own size and metric.

A point is an identifier, one or more vectors and an optional payload. The identifier is a 64 bit integer or a UUID, and the payload is arbitrary JSON. Dense vectors come from most embedding models, sparse vectors serve token level matching.

• Upserts are idempotent: an existing identifier is overwritten.
• A modification lands in the write ahead log first, which survives a power loss, then in the segments.

Distance metrics

Four metrics are documented: dot product, cosine similarity, Euclidean distance and Manhattan distance.

• Cosine is the usual choice for text embeddings: normalizing at insertion reduces the comparison to a dot product that SIMD instructions accelerate.
• Dot suits unnormalized vectors, where magnitude carries meaning, while Euclid and Manhattan come up when scale or a taxicab style distance matters.

Payload filtering and indexes

An embedding does not carry everything that matters commercially: stock, user location, price or date. A search can therefore carry conditions on the payload and the identifier, nested recursively: must is AND, should is OR and must_not is negation.

Two things decide how fast filtering is. The first is the payload index: keyword, integer, float, bool, geo, datetime and text indexes exist, and without one the engine scans the whole collection. The second is query planning, which picks between the payload index, the filterable HNSW graph and a full scan.

• Payload indexes are best created before ingesting data, because the filterable HNSW only gains filter aware edges when the index already existed.
• In strict mode a query on an unindexed field can be rejected, so a missing index surfaces as an error instead of silent slowness.
• One collection with a tenant keyed payload index is the documented approach for many tenants.

The HNSW index and the API surface

Speed comes from the HNSW graph, where each point links to its neighbours with at most m edges and a search descends layer by layer towards the query vector. m and ef_construct are build parameters, hnsw_ef is set per query.

Not every segment gets an index automatically, so below the optimizer threshold a full scan runs.

The REST API listens on port 6333, with the documented query endpoint POST /collections/{collection_name}/points/query. The gRPC API on port 6334 serves high throughput batched loading and backs the Rust, Java, C# and Go clients.

• Vector search is approximate by design: exact=true forces a full scan for exact results.
• indexed_only skips segments without an index and may return a partial result.

What to watch

• Building the index takes time, and raising m, ef_construct or payload_m increases build time and memory use.
• Memory is dominated by the vectors: a dimension costs four bytes. The graph and the payload indexes add to that, and the cached memory tier preloads them into RAM.
• Quantization gives 4x compression with scalar and up to 32x with binary, but adds an approximation error.
• Results are approximate: accuracy depends on m, ef_construct, hnsw_ef and quantization.

Further reading

• Local Quickstart
• Collections
• Quantization

At CyberElectro Qdrant is the vector search layer behind our retrieval features. Source records stay in PostgreSQL.