Qdrant Vocabulary: English for Vector Search Engineers

Qdrant is one of the most widely adopted vector databases in production AI systems, powering semantic search, recommendation engines, and retrieval-augmented generation pipelines. If you work with Qdrant and collaborate with English-speaking teams, you will quickly discover that precise vocabulary matters enormously — a misunderstood term in a code review or architecture discussion can lead to costly mistakes. This guide walks through the essential English vocabulary you need to read documentation, ask good questions, and hold confident technical conversations about Qdrant.

Key Vocabulary

Collection — A named container that holds all the points (vectors and their metadata) for a specific use case. Collections are the top-level organisational unit in Qdrant, similar to a table in a relational database. “We created a separate collection for each customer’s document set to keep the data isolated.”

Vector — A numerical array (a list of floating-point numbers) that represents the semantic meaning of a piece of data. Vectors are produced by embedding models and are the core data type that Qdrant stores and searches. “Each product description is converted to a 1536-dimensional vector before being upserted into the collection.”

Payload — Structured metadata attached to a point alongside its vector. Payloads can store any JSON-compatible data — text, numbers, booleans, or arrays — and are used for filtering search results. “We store the document title, category, and publication date in the payload so we can filter results by date range without re-ranking.”

HNSW Index — Short for Hierarchical Navigable Small World, this is the graph-based index structure Qdrant uses to perform fast approximate nearest neighbour search. HNSW trades a small amount of recall accuracy for dramatically faster query times at scale. “After tuning the HNSW index parameters, our p99 query latency dropped from 80 ms to 12 ms on a collection of ten million points.”

Sparse Vector — A vector in which the vast majority of values are zero, with only a small number of non-zero entries. Sparse vectors are commonly produced by keyword-based methods such as BM25 or SPLADE and complement dense vectors in hybrid search setups. “By combining a dense semantic vector with a sparse keyword vector, we improved recall on queries containing rare domain-specific terms.”

Multitenancy — An architectural pattern in which a single Qdrant collection serves multiple independent users or organisations, using payload fields or named vectors to keep each tenant’s data logically separated. This avoids the overhead of creating thousands of individual collections. “Our SaaS product uses a multitenancy approach with a tenant_id payload field and strict filtering to ensure no data leaks between customers.”

Quantisation — A technique that reduces the memory footprint of stored vectors by representing each floating-point number with fewer bits — for example, converting 32-bit floats to 8-bit integers or even 1-bit binary values. Qdrant supports scalar, product, and binary quantisation. “Enabling scalar quantisation reduced our memory usage by roughly four times with only a marginal drop in search accuracy.”

Named Vectors — A feature that allows a single point in Qdrant to store multiple distinct vectors under different names, each representing the same object from a different embedding model or modality. “We use named vectors to store both a text embedding and an image embedding for each product, then query whichever is most appropriate at runtime.”

Useful Phrases

Here are sentences you will commonly hear and say when working with Qdrant in an English-speaking engineering environment:

• “Let’s upsert the new embeddings into the collection — upsert means insert if the point doesn’t exist, or update it if it does.”
• “We need to add a payload index on the category field before we can filter efficiently at this scale.”
• “The ef parameter in the HNSW search config controls the size of the candidate set — higher values improve recall but increase latency.”
• “Can you check whether quantisation is enabled on that collection? It might explain the memory spike we saw in the dashboard.”
• “We’re planning to shard the collection across multiple nodes to handle the projected growth over the next quarter.”
• “The scroll API lets you paginate through all points in a collection without doing a vector similarity search.”

Common Mistakes

Confusing “collection” with “index”

Engineers coming from Elasticsearch or OpenSearch often call a Qdrant collection an “index.” In Qdrant, an index refers specifically to the HNSW graph structure built inside a collection to speed up search. Saying “I’ll create a new index for the product data” will confuse teammates — say “collection” instead.

Mispronouncing or miswriting “quantisation”

In British English, the correct spelling is quantisation (with an s), not “quantization.” More importantly, engineers sometimes confuse quantisation (compressing vector precision) with quantisation error (the accuracy loss that results from it). When raising a concern in a review, be specific: “quantisation is enabled” versus “we’re seeing high quantisation error.”

Treating “payload” and “metadata” as always interchangeable

In general conversation they often mean the same thing, but in Qdrant documentation “payload” has a specific technical meaning — it is the structured JSON object attached to a point. Using “metadata” when writing Qdrant-specific tickets or documentation can cause confusion because the official API, SDK methods, and configuration keys all use the term payload.

Building fluency in Qdrant’s technical vocabulary will make you a more effective collaborator on AI search projects. When you can articulate the difference between a dense vector and a sparse vector, or explain why quantisation affects recall, your contributions to architecture discussions and code reviews become far more valuable. Keep this vocabulary close as you read the Qdrant documentation and explore its rich feature set.