Specifying using narrows the search to one index; omitting it multiplies the work
When a collection has multiple named vectors, a query that specifies using="field" searches only that field's index. A query that does not specify using is ambiguous: the engine either errors or, depending on the version and the collection shape, searches across all named vectors and merges the results. Searching all named vectors means running one HNSW traversal per field, plus a merge across fields, so the cost is roughly N times the cost of a single-field search plus the merge overhead. For a collection with three or four named vectors, that is a 3-4x cost multiplier on the search path, and it also fetches and scores vectors for fields you did not intend to query. Specifying using is therefore not just a convenience - it is a performance decision that determines how many graph traversals a single query triggers.
The mechanism is that each named vector has its own independent index. There is no shared structure between them, so searching all of them means traversing each graph separately. If the fields have different dimensions or distance metrics, the scores are not directly comparable, and merging them requires either a fusion step or a score normalization. If the fields have the same dimension and metric, the merge is a simple score sort, but the work is still N traversals. The practical guidance is to always specify using when the collection has more than one named vector, and to specify it in prefetch stages as well, because a prefetch without using is equally ambiguous. There is a related but different cost: touching every named vector for retrieval - for example, returning all vectors in the response via with_vectors=True - is a separate cost from searching them, and returning large multivectors in the payload can dominate the response size.
Single named vector: using= can be omitted if the collection has only one unnamed vector.
Multiple named vectors: using= must be specified, or the request is ambiguous and either errors or searches all fields.
Cost multiplier: searching N named vectors means N HNSW traversals plus a merge, roughly N times the single-field cost.
Prefetch stages: the same rule applies; a prefetch without using is ambiguous.
Retrieval cost: with_vectors=True returns the vector payload, which is a separate cost from the search and can be large for multivectors.
The trade-off is flexibility against cost. Multi-vector collections let you model different aspects of a document (title, body, image) and query each independently or combine them, which is powerful. But each field has its own index, and querying all of them is expensive. The common mistake is copying a query example from a single-vector collection and forgetting to add using= when adapting it to a multi-vector collection, which either fails or silently searches every field and inflates latency. The second mistake is assuming that specifying using= changes the results semantically - it does not, it just picks which index to search; the results are the same as a single-field search, but faster. The third mistake is forgetting that with_vectors=True on a multivector field returns all token vectors in the response, which can be hundreds of vectors per point and dominate serialization time. Version note: the requirement to specify using on multi-vector collections, the exact error or fallback behavior when it is omitted, and the query_points API shape are all version-dependent; older clients may have different defaults for how an unspecified vector is handled.
Version-dependent: the behavior when using= is omitted on a multi-vector collection has changed across releases - some versions error, some search all fields, and the query_points API replaced the older search/search_batch calls in qdrant-client 1.10+. If you are porting code across versions, verify how the client handles an unspecified vector, and always set using= explicitly on multi-vector collections and on prefetch stages to avoid version-dependent ambiguity.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
